Google Trust Services roots

[Peter Bowen]

A couple of weeks ago, Google announced Google Trust Services
(https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html)
and also announced that they have acquired two roots that are in
Mozilla trust store.

As discussed in this group previously, Mozilla does not have a very
clear policy on root transfer, but does have a clear policy on audit
requirements and disclosure. Based on the material published in the
blog and at the Google Trust Services website (https://pki.goog), I'm
not clear that the transfer and operation meets Mozilla's
requirements.

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 certificates.

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.

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
(https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not
appear to align with Mozilla requirements for public disclosure.

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.

I realize the discussion period for Google's inclusion request is
likely many months off, I believe that it is important to address
these issues soon, as they impact roots currently in the Mozilla CA
program.

Thanks,
Peter

[Gervase Markham]

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
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). 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 mozilla.dev.security.policy are
correct. So CCing Ryan Hurst of GTS for a response.

Gerv

[Ryan Hurst]

Peter,

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 certificates.

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 OIDs,
- Google issuing a certificate with the GlobalSign OIDs would qualify as miss-issuance.

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 (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not appear to align with Mozilla requirements for public disclosure.

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 material.

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 future.

Ryan Hurst
Google, Inc.

[Ryan Hurst]

Peter,

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
certificates.

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 (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532).
This does not appear to align with Mozilla requirements for public
disclosure.

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.

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 <ge...@mozilla.org> 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
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not
> > appear to align with Mozilla requirements for public disclosure.
>

[Peter Bowen]

Ryan,

Thank you for the quick reply. My comments and questions are inline.

On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> Peter,
>
> 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.

Where I see opportunities below, I'm marking them with "Policy Suggestion".

> 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 certificates.
>
> 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 OIDs,
> - Google issuing a certificate with the GlobalSign OIDs would qualify as miss-issuance.

Mozilla recognizes 2.23.140.1.1 as being a valid OID for EV
certificates for all EV-enabled roots
(https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).

1) Do you consider it mis-issuance for Google to issue a certificate
containing the 2.23.140.1.1 OID?

Policy Suggestion A) When transferring a root that is EV enabled, it
should be clearly stated whether the recipient of the root is also
receiving the EV policy OID(s).

> 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.

It was not.

2) Will Google be publishing an audit report for a period starting 11
August 2016 that covers the transferred GS roots? If so, can you
estimate the end of period date?

> 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 (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not appear to align with Mozilla requirements for public disclosure.
>
> 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.

I think that this is the key issue. In my reading, "root
certificates" are not members of the program. Rather organizations
(legal entities) are members and each member has some number of root
certificates.

Google was not a member of the program and had not applied to be a
member of the program at the time they received the roots already in
the program. This seems problematic to me.

Policy Suggestion B) Require that any organization wishing to become a
member of the program submit a bug with links to content demonstrating
compliance with the Mozilla policy. Require that this be public prior
to taking control of any root in the program.

Policy Suggestion C) Recognize that root transfers are distinct from
the acquisition of a program member. Acquisition of a program member
(meaning purchase of the company) is a distinctly different activity
from moving only a private key, as the prior business controls no
longer apply in the latter case.

> 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 material.
>
> 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.

I don't see how having a subordinate issuing CA leads to the
conclusion that they have "facilities and procedures appropriate for
offline key management". Running an online and offline CA are two
rather different things and usually have different controls.

Policy Suggestion D) Moving from being a RA to a CA or moving from
being a single tier/online (i.e. Subordinate-only) CA to being a
multi-tier/root CA requires a PITRA

> 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.

I disagree. There is no evidence of operational controls over
Subordinate CA Certificate Life Cycle Management. This is highlighted
by the fact that the neither the management assertion nor the opinion
list this topic at all.

3) Does Google have audited controls around offline operations and
Subordinate CA certificate issuance?

One more item: The GTS CPS says that "Between 11 August 2016 and 8

December 2016, Google Inc. operated these Roots according to Google

Inc.’s Certification Practice Statement." The latest Google Inc CPS I
could find is the one dated July 2016
(http://static.googleusercontent.com/media/pki.google.com/en/GIAG2-CPS-1.4.pdf).

The Google CPS says "The Google Internet Authority may issue
Subscriber Certificates only to the following organizations: Google
and Google Affiliates."

4) Do you believe that this restriction is appropriate for roots in
the Mozilla program?

The Google CPS says it only covers Google Internet Authority G2.

5) Is there a version of the CPS that covers the GS roots?

> 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 agree creation of a new CA under the existing audited controls does
not require a pre-issuance audit. However that is not applicable to
this case.

> 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 future.

Thanks,
Peter

[Jakob Bohm]

On 09/02/2017 20:55, Ryan Hurst wrote:
> Peter,
>
> 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 certificates.
>
> rmh: Prior to our final stage of the acquisition we contacted both Mozilla and Microsoft about this particular situation.
>

Additional issue #1: Apparently, GlobalSign has not updated its website
with the fact that GlobalSign root R2 is no longer operated by
GlobalSign, see for example
https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates
..

Also looking at the GlobalSign website I saw no obvious press release
regarding this transfer, the closest I could find was the following,
which seems kind of misleading, as it mentions new EV certs chaining to
GlobalSign R3 instead of R2, but not the fact that R2 is no longer a
GlobalSign root:
https://support.globalsign.com/customer/portal/articles/2580816-ev-ssl-intermediate-and-root-changes

Additional issue #2: The information at https://pki.goog/ about how to
report misissuance directs visitors to a generic reporting page for
code vulnerabilities, which (by their nature) tends to require reaction
times measured in days/weeks rather than the 1 day maximum specified
in Google's CPS.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> Additional issue #2: The information at https://pki.goog/ about how to
> report misissuance directs visitors to a generic reporting page for
> code vulnerabilities, which (by their nature) tends to require reaction
> times measured in days/weeks rather than the 1 day maximum specified
> in Google's CPS.
>

(To be clear, I am responding only as an individual, neither as Mozilla
peer or Google employee, although I recognize you will likely disregard my
remarks regardless.)

In the past, such comments have generally been seen as offtopic/accusatory,
because they are inherently absent of evidence of any malfeasance. Indeed,
your very comment seems to suggest that Google is not adhering to its
CP/CPS, but without evidence, and such implication comes not based on any
action that Google has taken, but based on your view of what 'others' do or
the 'class' of bugs.

I highlight this because we (the community) see the occasional remark like
this; most commonly, it's directed at organizations in particular
countries, on the basis that we shouldn't trust "them" because they're in
one of "those countries". However, the Mozilla policy is structured to
provide objective criteria and assessments of that.

In this case, I do not believe you are being accurate or fair to present it
as an "issue"; you are implying that Google will not adhere to its CP/CPS,
but without evidence. The nature of incident reporting via this method may
indeed be risky, but it's neither forbidden nor intrinsically wrong. If you
look at many members in the Mozilla program, you will see far less
specificity as to a problem report and the acceptable means of reporting
this.

So while it's useful for you to draw attention to this, it's without
evidence or basis for you to suggest that this is an "issue", per se - that
is, it seemingly in no way conflicts with Mozilla policy or industry
practice.

[Richard Wang]

I can't see this sentence

" I highlight this because we (the community) see the occasional remark like this; most commonly, it's directed at organizations in particular countries, on the basis that we shouldn't trust "them" because they're in one of "those countries". However, the Mozilla policy is structured to provide objective criteria and assessments of that."

has any relationship with this topic, please advise, thanks.


Best Regards,

Richard

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Bowen]

On Thu, Feb 9, 2017 at 9:56 PM, Richard Wang via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> I can't see this sentence
> " I highlight this because we (the community) see the occasional remark like this; most commonly, it's directed at organizations in particular countries, on the basis that we shouldn't trust "them" because they're in one of "those countries". However, the Mozilla policy is structured to provide objective criteria and assessments of that."
> has any relationship with this topic, please advise, thanks.

I think the point is that issues raised about CAs need to be grounded
in fact. "Universal Trust Services wrote Y in their CPS but did not
do Y as demonstrated by Z" is something that can be evaluated
factually "UTS wrote Y in their CPS but might not being doing Y"
without any evidence is not something that can be evaluated factually.

I agree with Ryan; we tend to see the second type of issue come up
more often with CAs from certain countries. This sort of non-data
driven issue is not appropriate to raise. Instead show what should
have happened and what did not.

Thanks,
Peter

[Jakob Bohm]

On 10/02/2017 05:42, Ryan Sleevi wrote:
>
>
> On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy
> <dev-secur...@lists.mozilla.org

> <mailto:dev-secur...@lists.mozilla.org>> wrote:
>
> Additional issue #2: The information at https://pki.goog/ about how to
> report misissuance directs visitors to a generic reporting page for
> code vulnerabilities, which (by their nature) tends to require reaction
> times measured in days/weeks rather than the 1 day maximum specified
> in Google's CPS.
>
>
> (To be clear, I am responding only as an individual, neither as Mozilla
> peer or Google employee, although I recognize you will likely disregard
> my remarks regardless.)
>
> In the past, such comments have generally been seen as
> offtopic/accusatory, because they are inherently absent of evidence of
> any malfeasance. Indeed, your very comment seems to suggest that Google
> is not adhering to its CP/CPS, but without evidence, and such
> implication comes not based on any action that Google has taken, but
> based on your view of what 'others' do or the 'class' of bugs.
>

> I highlight this because we (the community) see the occasional remark
> like this; most commonly, it's directed at organizations in particular
> countries, on the basis that we shouldn't trust "them" because they're
> in one of "those countries". However, the Mozilla policy is structured
> to provide objective criteria and assessments of that.
>

> In this case, I do not believe you are being accurate or fair to present
> it as an "issue"; you are implying that Google will not adhere to its
> CP/CPS, but without evidence. The nature of incident reporting via this
> method may indeed be risky, but it's neither forbidden nor intrinsically
> wrong. If you look at many members in the Mozilla program, you will see
> far less specificity as to a problem report and the acceptable means of
> reporting this.
>

For clarity, I was pointing out that GTS seems to have chosen a method
likely to fail if an when actually needed, due to the typical dynamics
of large human organizations. Presumably an organization of such
magnitude is likely to have contact points more dedicated to
time-sensitive action-required messages than the contact point they chose.

> So while it's useful for you to draw attention to this, it's without
> evidence or basis for you to suggest that this is an "issue", per se -
> that is, it seemingly in no way conflicts with Mozilla policy or
> industry practice.

I find that it is an issue, but not an absolute cause for rejection.

[Gervase Markham]

Hi Ryan,

On 09/02/17 19:55, Ryan Hurst wrote:
> - The EV OID associated with this permission is associated with GlobalSign and not Google and,

Which EV OID are you referring to, precisely?

> - 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 OIDs,
> - Google issuing a certificate with the GlobalSign OIDs would qualify as miss-issuance.
>
> 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).

Just to be clear: GlobalSign continues to operate at least one subCA
under a root which Google has purchased, and that root is EV-enabled,
and the sub-CA continues to do EV issuance (and is audited as such) but
the root is no longer EV audited, and nor is the rest of the hierarchy?

> 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.

Can you tell us what the planned start/end dates for the audit period of
that annual audit are/will be?

Are the Google roots and/or the GlobalSign-acquired roots currently
issuing EE certificates? Were they issuing certificates between 11th
August 2016 and 8th December 2016?

Gerv

[Ryan Sleevi]

On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> For clarity, I was pointing out that GTS seems to have chosen a method
> likely to fail if an when actually needed, due to the typical dynamics
> of large human organizations. Presumably an organization of such
> magnitude is likely to have contact points more dedicated to
> time-sensitive action-required messages than the contact point they chose.
>
> So while it's useful for you to draw attention to this, it's without
>> evidence or basis for you to suggest that this is an "issue", per se -
>> that is, it seemingly in no way conflicts with Mozilla policy or
>> industry practice.
>>
>
> I find that it is an issue, but not an absolute cause for rejection.

I think Peter's response basically highlights why this is not an issue, at
least how Mozilla has historically determined them:

"I think the point is that issues raised about CAs need to be grounded in
fact. "Universal Trust Services wrote Y in their CPS but did not do Y as
demonstrated by Z" is something that can be evaluated factually "UTS wrote
Y in their CPS but might not being doing Y" without any evidence is not
something that can be evaluated factually."

Basically, the issue you're raising is, even in the most charitable sense,
not an actionable grounds for rejection - even in part - which you seem to
believe it is ("but not an absolute cause for rejection" - implying it
contributes to some sum total of issues). It might be an opportunity for
the CA to reconsider things, but in the same way that "But the Government
of X might require the CA to do something" is free of evidence and cannot
be evaluated factually, "But they might not abide by the BRs" is free of
evidence and cannot be evaluated factually. It's simply noise.

[Jakob Bohm]

On 10/02/2017 16:34, Ryan Sleevi wrote:
> On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>>
>> For clarity, I was pointing out that GTS seems to have chosen a method
>> likely to fail if an when actually needed, due to the typical dynamics
>> of large human organizations. Presumably an organization of such
>> magnitude is likely to have contact points more dedicated to
>> time-sensitive action-required messages than the contact point they chose.
>>
>> So while it's useful for you to draw attention to this, it's without
>>> evidence or basis for you to suggest that this is an "issue", per se -
>>> that is, it seemingly in no way conflicts with Mozilla policy or
>>> industry practice.
>>>
>>
>> I find that it is an issue, but not an absolute cause for rejection.
>
>

I am trying to say that I use the word "issue" as the weakest category,
orders of magnitude less serious than an absolute cause for rejection.

[Ryan Sleevi]

On Fri, Feb 10, 2017 at 8:00 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I am trying to say that I use the word "issue" as the weakest category,

> orders of magnitude less serious than an absolute cause for rejection.


And I'm trying to suggest that it's in the category that is below the floor
acceptable for discussion in the group, because it's purely speculative and
without ability to evaluate.

It might be appropriate to raise as a "suggestion" during a public review
phase (which this is not), but that it's misleading and misrepresenting to
suggest it's an "issue" with any weight whatsoever, precisely because it's
absent factual detail and cannot be evaluated in any way - much like
statements such as "Government X might do Y to this CA", which is no more
valuable than a statement "Unicorns might exist and be morally repulsed by
this particular arrangement of words in the CPS". Yes, it's a possibility,
but it's in no way actionable, and it's certainly not appropriate to
suggest that, say, Mozilla should require the CA to change the sequence, to
avoid offending the Unicorns and thus bringing about the destruction of
Earth.

[Peter Bowen]

Ryan,

Both Gerv and I posted follow up questions almost two weeks ago. I
know you have been busy with CT days. When do you expect to have
answers available?

Thanks,
Peter

On Fri, Feb 10, 2017 at 2:01 AM, Gervase Markham via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> Hi Ryan,
>
> On 09/02/17 19:55, Ryan Hurst wrote:

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

> Which EV OID are you referring to, precisely?
>

>> - 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 OIDs,
>> - Google issuing a certificate with the GlobalSign OIDs would qualify as miss-issuance.
>>
>> 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).
>

> Just to be clear: GlobalSign continues to operate at least one subCA
> under a root which Google has purchased, and that root is EV-enabled,
> and the sub-CA continues to do EV issuance (and is audited as such) but
> the root is no longer EV audited, and nor is the rest of the hierarchy?
>

>> 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.
>

> Can you tell us what the planned start/end dates for the audit period of
> that annual audit are/will be?
>
> Are the Google roots and/or the GlobalSign-acquired roots currently
> issuing EE certificates? Were they issuing certificates between 11th
> August 2016 and 8th December 2016?
>
> Gerv

[Gervase Markham]

Ryan H,

On 23/02/17 04:40, Peter Bowen wrote:
> Both Gerv and I posted follow up questions almost two weeks ago. I
> know you have been busy with CT days. When do you expect to have
> answers available?

Ping? :-)

Gerv

[Ryan Hurst]

[Trying to resend without the quoted email to get through the spam filter]

First, let me apologize for the delay in my response, I have had a draft of
this letter in my inbox for a while and have just been unable to get back
to it and finish it due to scheduling conflicts. I promise to address all
other questions in a more prompt manner.

> pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for
EVcertificates for all EV-enabled roots

> (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).

> 1) Do you consider it mis-issuance for Google to issue a certificate
containing the 2.23.140.1.1 OID?

> Policy Suggestion A) When transferring a root that is EV enabled, it
should be clearly stated whether the
> recipient of the root is also receiving the EV policy OID(s).

rmh: Yes. We believe that until we have:
- The associated policies, procedures, and other associated work completed,
- Have successfully completed an EV audit,
- And have been approved by one or more of the various root programs as an
EV issuer.

That it would be an example of miss-issuance for us to issue such a
certificate.



> 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.

> It was not.

rmh: I just attached two opinion letters from our auditors, I had
previously provided these to the root programs directly but it took some
time to get permission to release them publicly. One letter is covering the
key generation ceremony of the new roots, and another covering the transfer
of the keys to our facilities. In this second report you will find the
following statement:

```
In our opinion, as of November 17, 2016, Google Trust Services LLC
Management’s Assertion, as referred to above, is fairly stated, in all
material respects, based on Certification Practices Statement Management
Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key
Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
Criteria for Certification Authorities v2.0.
```

Based on our conversations with the various root program operator's prior
to our acquisition it has been our plan and understanding, that we can
utilize these opinion letters to augment the webtrust audit with the
material details, relating to these activities. It is our hope that this
also addresses you specific concern here.

> 2) Will Google be publishing an audit report for a period starting 11
> August 2016 that covers the transferred GS roots? If so, can you
> estimate the end of period date?

rmh: It is our belief, based on our conversations with the various root
store operators, as well as our own auditors that the transfer itself is
covered by the opinion letters. With that said our audit period is October
1st to the end of September. The associated report will be released between
October and November, depending on our auditors schedules.


> pzb: I think that this is the key issue. In my reading, "root

> certificates" are not members of the program. Rather organizations
> (legal entities) are members and each member has some number of root
> certificates.

> Google was not a member of the program and had not applied to be a
> member of the program at the time they received the roots already in
> the program. This seems problematic to me.

> Policy Suggestion B) Require that any organization wishing to become a
> member of the program submit a bug with links to content demonstrating
> compliance with the Mozilla policy. Require that this be public prior
> to taking control of any root in the program.

> Policy Suggestion C) Recognize that root transfers are distinct from
> the acquisition of a program member. Acquisition of a program member
> (meaning purchase of the company) is a distinctly different activity
> from moving only a private key, as the prior business controls no
> longer apply in the latter case.

We discussed the topic of disclosure with the root program administrators
prior to our acquisition. Our goal was to tell the community as soon as
possible, the complexity of this transaction made it hard to get a hard
date for that announcement. Based on our conversations with root program
administrators we were told the policy did not require disclosure to be
public which left the timing of that notification up to us.

As for the recommendation to clarify the policy in this area, I think it
would be valuable to do that.

Both of your recommendations seem reasonable, my concern with B) is how to
do so in a way that does not make it impossible or even more complicated to
successfully negotiate such a deal. As long as the disclosure was limited
to intent to become a member then I think that goal would be achieved.


> pzb: I don't see how having a subordinate issuing CA leads to the

> conclusion that they have "facilities and procedures appropriate for
> offline key management". Running an online and offline CA are two
> rather different things and usually have different controls.

rmh: We understand this concern. We believe that not all operators of a
subordinate CA have the policies and procedures to effectively manage a
root ca and its keys. However, in our case, for various reasons, Google did
have the associated policies and procedures. Prior to the acquisition we
discussed this situation with the browser root programs, and mutually came
to the conclusion that relying on the opinion letters from the auditors to
demonstrate these would be sufficient.

> Policy Suggestion D) Moving from being a RA to a CA or moving from
> being a single tier/online (i.e. Subordinate-only) CA to being a
> multi-tier/root CA requires a PITRA

> 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.

>pzb: I disagree. There is no evidence of operational controls over

> Subordinate CA Certificate Life Cycle Management. This is highlighted
> by the fact that the neither the management assertion nor the opinion
> list this topic at all.

First, for others, Google was, and is, operating as a subordinate CA with
its own facilities, policies, and procedures and not an RA. As part of
this, Google has maintained operational policies, procedures for all the
common processes, including but not limited to generation and CA keys,
managing offline keys, generating and publishing CRLs, OCSP responses, and
incident response.

In the opinion letter you will find the following statement:

```
In our opinion, as of November 17, 2016, Google Trust Services LLC
Management’s Assertion, as referred to above, is fairly stated, in all
material respects, based on Certification Practices Statement Management
Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key
Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
Criteria for Certification Authorities v2.0.
```

It was both our hope and understanding that this is sufficient to concern
here.

As you have noted to me personally in the past you found it odd that Google
generated a new GIAG2 regularly, this is a function of the way Symantec has
structured our agreement with them. This required, as you might imagine,
Google to have developed and maintained the frameworks to support this
activity.

If there are issues here with the scope of the opinion letter as worded, I
would be happy to work with the auditors to clarify it.



> pzb: One more item: The GTS CPS says that "Between 11 August 2016 and 8

> December 2016, Google Inc. operated these Roots according to Google

> Inc.’s Certification Practice Statement." The latest Google Inc CPS I
> could find is the one dated July 2016
(
http://static.googleusercontent.com/media/pki.google.com/en/GIAG2-CPS-1.4.pdf
).

We determine we were not explicit enough in the original publication of the
GTS CPS, for this reason we updated it (
http://static.googleusercontent.com/media/pki.goog/en//GTS-CPS-1.5.pdf) and
it now states:

“Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS
Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to
GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice
Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated
these Roots according to Google Inc.’s Certification Practice Statement. As
of 9 December 2016, Google Trust Services LLC operates these Roots under
Google Trust Services LLC’s Certificate Policy and Certification Practice
Statement.”

It is our hope this makes it clearer.


> pzb The Google CPS says "The Google Internet Authority may issue

> Subscriber Certificates only to the following organizations: Google
> and Google Affiliates."

> 4) Do you believe that this restriction is appropriate for roots in
> the Mozilla program?

This statement reflects the contractual limitation Symantec has on Google
relative to GIAG2.

To your question of applicability, I believe it is appropriate in this
case. Google and Google Affiliates operate some of the most popular and
frequented sites on the web, as part of that Google often hosts customer
applications and content.

As I understand it, the goal of the Mozilla root program is to enable sites
just like these to offer their services over SSL. Enabling Google to do so
for its own properties and its customers seems well within the intent of
the program.


> pzb: The Google CPS says it only covers Google Internet Authority G2.

> 5) Is there a version of the CPS that covers the GS roots?

After a review of the GTS CPS, it became clear we were not sufficiently
clear when the transition from the GIAG2 CPS to the GTS CPS happened, as
per above we have since made a text clarification we hope addresses this
question:

“Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS
Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to
GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice
Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated
these Roots according to Google Inc.’s Certification Practice Statement. As
of 9 December 2016, Google Trust Services LLC operates these Roots under
Google Trust Services LLC’s Certificate Policy and Certification Practice
Statement.”


Ryan Hurst
Product Manager

[Ryan Hurst]

> Gerv: Which EV OID are you referring to, precisely?

I was referring to the GlobalSign EV Certificate Policy OID (1.3.6.1.4.1.4146.1.1) but more concretely I meant any and all EV related OIDs, including the CAB Forum OID of 2.23.140.1.1.

> Gerv: Just to be clear: GlobalSign continues to operate at least one subCA

> under a root which Google has purchased, and that root is EV-enabled,
> and the sub-CA continues to do EV issuance (and is audited as such) but
> the root is no longer EV audited, and nor is the rest of the hierarchy?

Yes, that is correct.

> Gerv: Can you tell us what the planned start/end dates for the audit period of

> that annual audit are/will be?

Our audit period is October 1st to the end of September. The associated report will be released between October and November, depending on our auditors schedules.

> Gerv: Are the Google roots and/or the GlobalSign-acquired roots currently

> issuing EE certificates? Were they issuing certificates between 11th
August 2016 and 8th December 2016?

No they were not issuing certificates between 11th August 2016 and 8th December 2016.

We generated our first certificate, a subordinate CA, last week, that CA is not yet in use.

Ryan Hurst
Product Manager

[Peter Bowen]

Ryan,

I appreciate you finally sending responses. I hope you appreciate
that they are clearly not adequate, in my opinion. Please see the
comments inline.

On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst <r...@google.com> wrote:
> First, let me apologize for the delay in my response, I have had a draft of
> this letter in my inbox for a while and have just been unable to get back to
> it and finish it due to scheduling conflicts. I promise to address all other
> questions in a more prompt manner.
>
>
>> pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for
>> EVcertificates for all EV-enabled roots
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).
>
>
>> 1) Do you consider it mis-issuance for Google to issue a certificate
>> containing the 2.23.140.1.1 OID?
>
>> Policy Suggestion A) When transferring a root that is EV enabled, it
>> should be clearly stated whether the
>> recipient of the root is also receiving the EV policy OID(s).
>
>
> rmh: Yes. We believe that until we have:
>
> - The associated policies, procedures, and other associated work completed,
>
> - Have successfully completed an EV audit,
>
> - And have been approved by one or more of the various root programs as an
> EV issuer.
>
>
> That it would be an example of miss-issuance for us to issue such a
> certificate.

Given the EV-enabled status, this seems like a reasonable path forward.

>> 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.
>

> covered by the opinion letters. With that said our audit period is October

> 1st to the end of September. The associated report will be released between
> October and November, depending on our auditors schedules.

This does not resolve the concern. The BRs require an "an unbroken
sequence of audit periods". Given that GlobalSign clearly cannot make
any assertion about the roots after 11 August 2016, you would have a
gap from 11 August 2016 to 30 September 2016 in your sequence of audit
periods if your next report runs 1 October 2016 to 30 September 2017.

Based on my personal experience, it is possible to negotiate a deal
and set a closing date in the future. This is standard for many
acquisitions; you frequently see purchases announced with a closing
date in the future for all kinds of deals. The gap between signing
the deal and closing gives acquirers the opportunity to complete the
steps in B.

You appear to be confusing things here. "Subordinate CA Certificate
Life Cycle Management" is the portion of the WebTrust criteria that
covers the controls around issuing certificates with the cA component
of the basicConstraints extension set to true. It has nothing to do
with operating a subordinate CA.

Given the BR limitations around use of root CA keys, this is the
critical portion of the certificate issuance criteria; very few
subscriber (e.g. non-CA) certificates are issued by root CAs.

> As you have noted to me personally in the past you found it odd that Google
> generated a new GIAG2 regularly, this is a function of the way Symantec has
> structured our agreement with them. This required, as you might imagine,
> Google to have developed and maintained the frameworks to support this
> activity.
>
> If there are issues here with the scope of the opinion letter as worded, I
> would be happy to work with the auditors to clarify it.
>

>> pzb: One more item: The GTS CPS says that "Between 11 August 2016 and 8

>> December 2016, Google Inc. operated these Roots according to Google

>> Inc.’s Certification Practice Statement." The latest Google Inc CPS I
>> could find is the one dated July 2016
> (http://static.googleusercontent.com/media/pki.google.com/en/GIAG2-CPS-1.4.pdf).
>
> We determine we were not explicit enough in the original publication of the
> GTS CPS, for this reason we updated it

> (http://static.googleusercontent.com/media/pki.goog/en//GTS-CPS-1.5.pdf) and

> it now states:
>
> “Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS
> Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to
> GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice
> Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated
> these Roots according to Google Inc.’s Certification Practice Statement. As
> of 9 December 2016, Google Trust Services LLC operates these Roots under
> Google Trust Services LLC’s Certificate Policy and Certification Practice
> Statement.”
>
> It is our hope this makes it clearer.

This is the exact text I quoted.

>> pzb The Google CPS says "The Google Internet Authority may issue
>> Subscriber Certificates only to the following organizations: Google
>> and Google Affiliates."
>
>> 4) Do you believe that this restriction is appropriate for roots in
>> the Mozilla program?
>
> This statement reflects the contractual limitation Symantec has on Google
> relative to GIAG2.
>
> To your question of applicability, I believe it is appropriate in this case.
> Google and Google Affiliates operate some of the most popular and frequented
> sites on the web, as part of that Google often hosts customer applications
> and content.
>
> As I understand it, the goal of the Mozilla root program is to enable sites
> just like these to offer their services over SSL. Enabling Google to do so
> for its own properties and its customers seems well within the intent of the
> program.

You have stated that the Google CPS (not the GTS CP/CPS) was the
applicable CPS for your _root CAs_ between 11 August 2016 and 8
December 2016. The Google CPS makes these statements. Therefore, you
are stating that the roots (not just GIA G2) were only permitted to
issue Certificates to Google and Google Affiliates. Mozilla has
consistently taken the position that roots that exclusively issue to a
single company are not acceptable in the root program.

>> pzb: The Google CPS says it only covers Google Internet Authority G2.
>
>> 5) Is there a version of the CPS that covers the GS roots?
>
> After a review of the GTS CPS, it became clear we were not sufficiently
> clear when the transition from the GIAG2 CPS to the GTS CPS happened, as per
> above we have since made a text clarification we hope addresses this
> question:
>
> “Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS
> Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to
> GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice

> Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated
> these Roots according to Google Inc.’s Certification Practice Statement. As
> of 9 December 2016, Google Trust Services LLC operates these Roots under
> Google Trust Services LLC’s Certificate Policy and Certification Practice
> Statement.”

This does not address the question. The Google CPS clearly states
that it only covers the GIA G2 CA. You have stated that the Google
CPS (not the GTS CP/CPS) was the applicable CPS for your _root CAs_
between 11 August 2016 and 8 December 2016. This puts your statement
at adds with what is written in the CPS.

I know that you appreciate the importance of clarity and transparency
in public CA operations and I hope you can clarify the issues with
your answers.

Thanks,
Peter

[Peter Bowen]

One more question, in addition to the ones in my prior response:

On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst <r...@google.com> wrote:
> rmh: I just attached two opinion letters from our auditors, I had previously
> provided these to the root programs directly but it took some time to get
> permission to release them publicly. One letter is covering the key
> generation ceremony of the new roots, and another covering the transfer of
> the keys to our facilities. In this second report you will find the
> following statement:
>
> ```
> In our opinion, as of November 17, 2016, Google Trust Services LLC
> Management’s Assertion, as referred to above, is fairly stated, in all
> material respects, based on Certification Practices Statement Management
> Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key

> Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
> Criteria for Certification Authorities v2.0.
> ```

According to the opinion letter:

"followed the CA key generation and security requirements in its:
o Google Internet Authority G2 CPS v1.4" (hyperlink omitted)

According to that CPS, "Key Pairs for the Google Internet Authority
are generated and installed in accordance with the contract between
Google and GeoTrust, Inc., the Root CA."

Are you asserting that the authority for the key generation process
for the new Google roots is "the contract between Google and GeoTrust,
Inc."?

Thanks,
Peter

[Ryan Hurst]

First, let me apologize for the delay in my response, I have had a draft of
this letter in my inbox for a while and have just been unable to get back
to it and finish it due to scheduling conflicts. I promise to address all
other questions in a more prompt manner.

> pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for
EVcertificates for all EV-enabled roots

> (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).

> 1) Do you consider it mis-issuance for Google to issue a certificate
containing the 2.23.140.1.1 OID?

> Policy Suggestion A) When transferring a root that is EV enabled, it
should be clearly stated whether the

> recipient of the root is also receiving the EV policy OID(s).

rmh: Yes. We believe that until we have:

- The associated policies, procedures, and other associated work completed,

- Have successfully completed an EV audit,

- And have been approved by one or more of the various root programs as an
EV issuer.

That it would be an example of miss-issuance for us to issue such a
certificate.

> 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.

> It was not.

rmh: I just attached two opinion letters from our auditors, I had
previously provided these to the root programs directly but it took some
time to get permission to release them publicly. One letter is covering the
key generation ceremony of the new roots, and another covering the transfer
of the keys to our facilities. In this second report you will find the
following statement:

```

In our opinion, as of November 17, 2016, Google Trust Services LLC
Management’s Assertion, as referred to above, is fairly stated, in all
material respects, based on Certification Practices Statement Management
Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key

Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
Criteria for Certification Authorities v2.0.

```

Based on our conversations with the various root program operator's prior
to our acquisition it has been our plan and understanding, that we can
utilize these opinion letters to augment the webtrust audit with the
material details, relating to these activities. It is our hope that this
also addresses you specific concern here.


> 2) Will Google be publishing an audit report for a period starting 11

> August 2016 that covers the transferred GS roots? If so, can you

> estimate the end of period date?

rmh: It is our belief, based on our conversations with the various root
store operators, as well as our own auditors that the transfer itself is
covered by the opinion letters. With that said our audit period is October
1st to the end of September. The associated report will be released between
October and November, depending on our auditors schedules.

In the opinion letter you will find the following statement:

```

In our opinion, as of November 17, 2016, Google Trust Services LLC
Management’s Assertion, as referred to above, is fairly stated, in all
material respects, based on Certification Practices Statement Management
Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key

Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
Criteria for Certification Authorities v2.0.

```

It was both our hope and understanding that this is sufficient to concern
here.

As you have noted to me personally in the past you found it odd that Google
generated a new GIAG2 regularly, this is a function of the way Symantec has
structured our agreement with them. This required, as you might imagine,
Google to have developed and maintained the frameworks to support this
activity.

If there are issues here with the scope of the opinion letter as worded, I
would be happy to work with the auditors to clarify it.

> pzb: One more item: The GTS CPS says that "Between 11 August 2016 and 8

> December 2016, Google Inc. operated these Roots according to Google

> Inc.’s Certification Practice Statement." The latest Google Inc CPS I

> could find is the one dated July 2016

(
http://static.googleusercontent.com/media/pki.google.com/en/GIAG2-CPS-1.4.pdf
).

We determine we were not explicit enough in the original publication of the
GTS CPS, for this reason we updated it (
http://static.googleusercontent.com/media/pki.goog/en//GTS-CPS-1.5.pdf) and
it now states:

“Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS
Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to
GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice
Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated
these Roots according to Google Inc.’s Certification Practice Statement. As
of 9 December 2016, Google Trust Services LLC operates these Roots under
Google Trust Services LLC’s Certificate Policy and Certification Practice
Statement.”

It is our hope this makes it clearer.

> pzb The Google CPS says "The Google Internet Authority may issue

> Subscriber Certificates only to the following organizations: Google

> and Google Affiliates."

> 4) Do you believe that this restriction is appropriate for roots in

> the Mozilla program?

This statement reflects the contractual limitation Symantec has on Google
relative to GIAG2.

To your question of applicability, I believe it is appropriate in this
case. Google and Google Affiliates operate some of the most popular and
frequented sites on the web, as part of that Google often hosts customer
applications and content.

As I understand it, the goal of the Mozilla root program is to enable sites
just like these to offer their services over SSL. Enabling Google to do so
for its own properties and its customers seems well within the intent of
the program.

> pzb: The Google CPS says it only covers Google Internet Authority G2.

> 5) Is there a version of the CPS that covers the GS roots?

After a review of the GTS CPS, it became clear we were not sufficiently
clear when the transition from the GIAG2 CPS to the GTS CPS happened, as
per above we have since made a text clarification we hope addresses this
question:

“Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS
Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to
GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice

Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated
these Roots according to Google Inc.’s Certification Practice Statement. As
of 9 December 2016, Google Trust Services LLC operates these Roots under
Google Trust Services LLC’s Certificate Policy and Certification Practice
Statement.”

Ryan Hurst

Product Manager

On Thu, Feb 9, 2017 at 2:55 PM, Peter Bowen <pzb...@gmail.com> wrote:

> Ryan,
>
> Thank you for the quick reply. My comments and questions are inline.
>
> On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy

> <dev-secur...@lists.mozilla.org> wrote:
> > Peter,
> >
> > 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.
>

> Where I see opportunities below, I'm marking them with "Policy Suggestion".
>

> > 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
> certificates.
> >

> > 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 OIDs,
> > - Google issuing a certificate with the GlobalSign OIDs would qualify as
> miss-issuance.
>

> Mozilla recognizes 2.23.140.1.1 as being a valid OID for EV
> certificates for all EV-enabled roots
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).
>
> 1) Do you consider it mis-issuance for Google to issue a certificate
> containing the 2.23.140.1.1 OID?
>
> Policy Suggestion A) When transferring a root that is EV enabled, it
> should be clearly stated whether the recipient of the root is also
> receiving the EV policy OID(s).
>

> > 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.
>
> It was not.
>

> 2) Will Google be publishing an audit report for a period starting 11
> August 2016 that covers the transferred GS roots? If so, can you
> estimate the end of period date?
>

> > 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 (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532).
> This does not appear to align with Mozilla requirements for public
> disclosure.
> >

> > 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.
>

> I think that this is the key issue. In my reading, "root
> certificates" are not members of the program. Rather organizations
> (legal entities) are members and each member has some number of root
> certificates.
>
> Google was not a member of the program and had not applied to be a
> member of the program at the time they received the roots already in
> the program. This seems problematic to me.
>
> Policy Suggestion B) Require that any organization wishing to become a
> member of the program submit a bug with links to content demonstrating
> compliance with the Mozilla policy. Require that this be public prior
> to taking control of any root in the program.
>
> Policy Suggestion C) Recognize that root transfers are distinct from
> the acquisition of a program member. Acquisition of a program member
> (meaning purchase of the company) is a distinctly different activity
> from moving only a private key, as the prior business controls no
> longer apply in the latter case.
>

> > 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
> material.
> >

> > 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.
>

> I don't see how having a subordinate issuing CA leads to the
> conclusion that they have "facilities and procedures appropriate for
> offline key management". Running an online and offline CA are two
> rather different things and usually have different controls.
>

> Policy Suggestion D) Moving from being a RA to a CA or moving from
> being a single tier/online (i.e. Subordinate-only) CA to being a
> multi-tier/root CA requires a PITRA
>
> > 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.
>

> I disagree. There is no evidence of operational controls over
> Subordinate CA Certificate Life Cycle Management. This is highlighted
> by the fact that the neither the management assertion nor the opinion
> list this topic at all.
>

> 3) Does Google have audited controls around offline operations and
> Subordinate CA certificate issuance?
>

> One more item: The GTS CPS says that "Between 11 August 2016 and 8

> December 2016, Google Inc. operated these Roots according to Google

> Inc.’s Certification Practice Statement." The latest Google Inc CPS I
> could find is the one dated July 2016
> (http://static.googleusercontent.com/media/pki.google.com/en/GIAG2-CPS-1.
> 4.pdf).
>

> The Google CPS says "The Google Internet Authority may issue
> Subscriber Certificates only to the following organizations: Google
> and Google Affiliates."
>
> 4) Do you believe that this restriction is appropriate for roots in
> the Mozilla program?
>

> The Google CPS says it only covers Google Internet Authority G2.
>
> 5) Is there a version of the CPS that covers the GS roots?
>

[Gervase Markham]

On 07/03/17 03:14, Ryan Hurst wrote:
>> Gerv: Just to be clear: GlobalSign continues to operate at least one subCA
>> under a root which Google has purchased, and that root is EV-enabled,
>> and the sub-CA continues to do EV issuance (and is audited as such) but
>> the root is no longer EV audited, and nor is the rest of the hierarchy?
>
> Yes, that is correct.

OK. Question for group: would it make sense to add the intermediate(s)
that GlobalSign is using for this purpose directly to the Mozilla trust
store, with the EV bit enabled, and then remove the EV bit from the
roots now owned by Google Trust Services?

This would scope EV permissions more closely to the audits, and so
prevent Google from accidentally or intentionally issuing EV which was
shown as such in Firefox, without having an EV audit.

Gerv

[Ryan Hurst]

> pzb: I appreciate you finally sending responses. I hope you appreciate

> that they are clearly not adequate, in my opinion. Please see the

> comments inline.

Again, sorry for the delay in responding, I will be more prompt moving
forward.

> pzb: This does not resolve the concern. The BRs require an "an unbroken

> sequence of audit periods". Given that GlobalSign clearly cannot make

> any assertion about the roots after 11 August 2016, you would have a

> gap from 11 August 2016 to 30 September 2016 in your sequence of audit

> periods if your next report runs 1 October 2016 to 30 September 2017.

I understand your point but this is not entirely accurate. Our strategy, to
ensure a smooth transition, which was reviewed with the auditors and root
program administrators was that we take possession of the root key material
and manage it offline, in accordance with our existing WebTrust audit and
the “Key Storage, Backup and Recovery Criterion”. It was our, and EY's
opinion that the existing controls and ongoing WebTrust audits were
sufficient given this plan and scope.

As such, during the period in question, the existing audits provide an
un-broken sequence of audit periods.

That said, we will follow-up with our auditors to see if it is possible to
extend the scope of our 2017 audit to also cover this interval to ensure
the community has further assurances of continuity.

> pzb: Based on my personal experience, it is possible to negotiate a deal

> and set a closing date in the future. This is standard for many

> acquisitions; you frequently see purchases announced with a closing

> date in the future for all kinds of deals. The gap between signing

> the deal and closing gives acquirers the opportunity to complete the

> steps in B.

As I stated, I think that moving forward this could be a good policy
change, I am hesitant to see any user agent adopt policies that are overly
prescriptive of commercial terms between two independent parties.


> pzb: You appear to be confusing things here. "Subordinate CA Certificate

> Life Cycle Management" is the portion of the WebTrust criteria that

> covers the controls around issuing certificates with the cA component

> of the basicConstraints extension set to true. It has nothing to do

> with operating a subordinate CA.

I am familiar with the "Subordinate CA Certificate Life Cycle Management"
controls

I just should have been more explicit in my earlier response.

These keys were generated and stored in accordance with Asset
Classification and Management Criterion, and Key Storage, Backup and
Recovery Criterion.

Before utilizing the associated keys in any activity covered by the
“Subordinate CA

Certificate Life Cycle Management” criterion all associated policies and
procedures were

created, tested and then reviewed by our auditors. Additionally, those
auditors were

present during the associated ceremony. All such activities which will be
covered under

our 2017 audit.

This is similar to how a CA can, and does, revise and extend their policies
between

audits to cover new products and services.

This is consistent with the approach we discussed, and had approved with
the various root program administrators.


> pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the

> applicable CPS for your _root CAs_ between 11 August 2016 and 8

> December 2016. The Google CPS makes these statements. Therefore, you

> are stating that the roots (not just GIA G2) were only permitted to

> issue Certificates to Google and Google Affiliates.

Correct, these roots were not used to issue certificates at all until last
week and when one was used, it was used to issue a subordinate CA
certificate to Google.

Though we do not have a product or service to announce currently, we can
say we will expand the use of GTS beyond GIAG2, at which time policies,
procedures, CP and CPS will be updated accordingly. This progression makes
sense as we're moving from a constrained intermediate to a Root.

> Mozilla has consistently taken the position that roots that exclusively
issue to a

> single company are not acceptable in the root program.

Google and its affiliate companies are more than a single company.

Additionally, clearly the intent of this rule is to prevent thousands of
organizations issuing a handful of certificates polluting the root store.

In the case of Google and its Affiliate companies, we operate products and
services for our

customers. This is similar to how Amazon and a number of other root
operators operate

products and services for their customers, the core difference being the
breadth of user

facing products we have.

> This does not address the question. The Google CPS clearly states

> that it only covers the GIA G2 CA. You have stated that the Google

> CPS (not the GTS CP/CPS) was the applicable CPS for your _root CAs_

> between 11 August 2016 and 8 December 2016. This puts your statement

> at adds with what is written in the CPS.

As stated previously, since Google already had a WebTrust audit in good
standing, and

that the acquisition happened inline with our standing regular audit, the
root program administrators agreed to the use of an opinion letter in lieu
of repeating the audit

90 days letter.

[Jakob Bohm]

Could a reasonably condition be that decision authority, actual and
physical control for a root are not moved until proper root program
coordination has been done (an action which may occur after/before the
commercial conclusion of a transaction). From a business perspective
this could be comparable to similar requirements imposed on some
physical objects that can have public interest implications.

Suggestion:

For clarity could Google and/or GTS issue a dedicated CP/CPS pair for
the brief period where Google (not GTS) had control of the former
GlobalSign root (such a CP/CPS would be particularly simple given that
no certificates were issued). Such as CP/CPS should also clarify any
practices and procedures for signing revocation related data (CRLs,
OCSP responses, OCSP responder certificates) from that root during the
transition. The CP/CPS would also need to somehow state that the
former GlobalSign issued certificates remain valid, though no further
such certificates were issued in this interim period.

Similarly could Google and/or GTS issue a dedicaed CP/CPS pair for the
new roots during the brief period where Google (not GTS) had control of
those new roots.

[Peter Kurrasch]

I&apos;m trying to keep score here but am having difficulties. Can someone confirm if the following statements are correct:<br/><br/>- Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products and services they choose to offer.<br/><br/>- No public announcement of the acquisition was made prior to January 26, 2017 via the Google security blog.<br/><br/>- No disclosure has been made regarding what specific items were acquired, including such things as: &quot;private key material&quot; (HSM&apos;s and whatnot); computer equipment used as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure used in the operations and maintenance of the acquired roots; data such as subscriber lists, server logs, payment details and histories, certificate issuance activities and histories, etc.; and any access rights to physical space such as offices, data centers, development and test facilities, and so forth.<br/><br/>- The scope of impact to existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google have notified any existing clients of the acquisition.<br/><br/>- The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Further, the web site does not make their CP/CPS documents readily available limiting the ability for current subscribers and relying parties to decide if continued use of a cert chaining up to these roots is acceptable for them.<br/><br/>- A relying party who actually takes the initiative to review a certificate chain will see that it is anchored (or &quot;verified by&quot;) GlobalSign. No mention of Google will be made anywhere.<br/><br/>- Google has acquired these roots in order to &quot;better serve&quot; their subscribers, which are organizations (not people) throughout the many Google companies. Relying parties are not affected positively or negatively by this acquisition. <br/><br/>- Mozilla granted Google&apos;s request to keep the acquisition confidential based on statements made by Google and Google&apos;s auditor E&amp;Y. GlobalSign nor their auditors offered any opinion on this matter.<br/><br/><br/>I&amp;apos;m trying to keep score here but am having difficulties. Can someone confirm if the following statements are correct:&lt;br/&gt;&lt;br/&gt;- Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products and services they choose to offer.&lt;br/&gt;&lt;br/&gt;- No public announcement of the acquisition was made prior to January 26, 2017 via the Google security blog.&lt;br/&gt;&lt;br/&gt;- No disclosure has been made regarding what specific items were acquired, including such things as: &amp;quot;private key material&amp;quot; (HSM&amp;apos;s and whatnot); computer equipment used as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure used in the operations and maintenance of the acquired roots; data such as subscriber lists, server logs, payment details and histories, certificate issuance activities and histories, etc.; and any access rights to physical space such as offices, data centers, development and test facilities, and so forth.&lt;br/&gt;&lt;br/&gt;- The scope of impact to existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google have notified any existing clients of the acquisition.&lt;br/&gt;&lt;br/&gt;- The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Further, the web site does not make their CP/CPS documents readily available limiting the ability for current subscribers and relying parties to decide if continued use of a cert chaining up to these roots is acceptable for them.&lt;br/&gt;&lt;br/&gt;- A relying party who actually takes the initiative to review a certificate chain will see that it is anchored (or &amp;quot;verified by&amp;quot;) GlobalSign. No mention of Google will be made anywhere.&lt;br/&gt;&lt;br/&gt;- Google has acquired these roots in order to &amp;quot;better serve&amp;quot; their subscribers, which are organizations (not people) throughout the many Google companies. Relying parties are not affected positively or negatively by this acquisition. &lt;br/&gt;&lt;br/&gt;- Mozilla granted Google&amp;apos;s request to keep the acquisition confidential based on statements made by Google and Google&amp;apos;s auditor E&amp;amp;Y. GlobalSign nor their auditors offered any opinion on this matter.&lt;br/&gt;&lt;br/&gt;&lt;br/&gt;

[Peter Kurrasch]

Previous attempt had a major formatting snafu. Resending.

From: Peter Kurrasch Sent: Tuesday, March 7, 2017 9:35 PM‎

I'm trying to keep score here but am having difficulties. Can someone confirm if the following statements are correct:

- Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products and services they choose to offer going forward. There is no affiliation or business relationship between GMO GlobalSign and Google after the completion of the acquisition.

- No public announcement of the acquisition was made prior to January 26, 2017 via the Google security blog.

- No disclosure has been made regarding what specific items were acquired, including such things as: "private key material" (HSM's and whatnot); computer equipment used as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure used in the operations and maintenance of the acquired roots; data such as subscriber lists, databases, server logs, payment details and histories, certificate issuance activities and histories, etc.; any access rights to physical space such as offices, data centers, development and test facilities, and so forth; and last, but not least, any personnel, documentation, training materials, or other knowledge products.

- The scope of impact to existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google have notified any existing clients of the acquisition.

- The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Further, the web site does not make their CP/CPS documents readily available limiting the ability for current subscribers and relying parties to decide if continued use of a cert chaining up to these roots is acceptable to them.

- A relying party who takes the initiative to review a certificate chain that goes up to either of the acquired roots will see that it is anchored (or "verified by") GlobalSign. No mention of Google will be made anywhere in the user interface.

- Google has acquired these roots in order to better serve their subscribers, which are organizations (not people) throughout the many Google companies. Relying parties (i.e. end users of the various Google products) are not affected positively or negatively by this acquisition.

- Mozilla granted Google's request to keep the acquisition confidential based on statements made by Google and Google's auditor E&Y. Neither GlobalSign nor their auditors offered any opinion on this matter.

Thank you.

[Gervase Markham]

On 08/03/17 03:54, Peter Kurrasch wrote:
> - Google has acquired 2 root certificates from GMO GlobalSign but not
> the ‎company itself.

Yes.

> GMO GlobalSign will continue to own other roots and
> will use only those other roots for the various products and services
> they choose to offer going forward.

Not quite. GMO GlobalSign continues to control some subCAs of the roots
it sold to Google, and is using those (presumably) to wind down its
interest in those roots over time or support customer migrations to
other roots. This happens to include issuing EV certificates.

> There is no affiliation or business
> relationship between GMO GlobalSign and Google after the completion of
> the acquisition.

We don't have information on this; the terms of the deal, and indeed any
other deals the two companies may have made, are not public.

> - No public announcement of the acquisition was made prior to January
> 26, 2017 via the Google security blog.

Depends what you mean by announcement, but they applied in a public bug
for inclusion in the Mozilla root program in December:
https://bugzilla.mozilla.org/show_bug.cgi?id=1325532
and, I think, announced their intention in a publicly-minuted meeting of
the CAB Forum in Redmond in mid-October 2016.

> - No disclosure has been made regarding what specific items were
> acquired, including such things as: "private key material" (HSM's and
> whatnot); computer equipment used as web servers, OCSP responders, etc.;
> domain names, IP addresses, and other infrastructure used in the
> operations and maintenance of the acquired roots; data such as
> subscriber lists, databases, server logs, payment details and histories,
> certificate issuance activities and histories, etc.; any access rights
> to physical space such as offices, data centers, development and test
> facilities, and so forth; and last, but not least, any personnel,
> documentation, training materials, or other knowledge products.

I have not seen such disclosure.

> - The scope of impact to existing GlobalSign customers is not known.

Well, as Globalsign continues to operate those subCAs, I would hope the
impact on GlobalSign customers is minimal.

> Neither GMO GlobalSign nor Google have notified any existing clients of
> the acquisition.

Unless we hear from such clients, we can't know this one way or the other.

> - The GlobalSign web site has no mention of this acquisition for reasons
> which are unknown.

Why would this be a requirement by anyone?

> Further, the web site does not make their CP/CPS
> documents readily available

Which website? The CP/CPS documents for which root(s)?

The GTS CP and CPS are here: http://pki.goog/.

> - A relying party who takes the initiative to review a certificate chain
> that goes up to either of the acquired roots will see that it is
> anchored (or "verified by") GlobalSign. No mention of Google will be
> made anywhere in the user interface.

I would expect there to be intermediate certificates with Google's name
in; it's not permitted to issue EE certs directly from a root. However,
neither GlobalSign's nor Google's name would appear in primary UI in
Firefox, as we don't display CA names.

> - Google has acquired these roots in order to better serve their
> subscribers, which are organizations (not people) throughout the many
> Google companies.

That's a question for Google.

> Relying parties (i.e. end users of the various Google
> products) are not affected positively or negatively by this acquisition.

That's a matter of opinion :-)

> - Mozilla granted Google's request to keep the acquisition confidential
> based on statements made by Google and Google's auditor E&Y.

That implies a cause and effect which is not present in the way
suggested. We require that changes of ownership be disclosed, but we
don't require them to be made public. Google and GlobalSign disclosed
this change of ownership in accordance with our requirements. We also
expect to see various audits which meet our auditing requirements over
any transition period; my understanding is that Kathleen was satisfied
with the documentation she saw. However, the keeping confidential of the
acquisition was not conditioned on the presentation of audit documentation.

> Neither
> GlobalSign nor their auditors offered any opinion on this matter.

Would you expect them to?

Gerv

[Gervase Markham]

Having gained a good understanding of Peter and Ryan's positions, I
think I am now in a position to evaluate Peter's helpful policy suggestions.

Whether or not we decide to make updates, as Kathleen pronounced herself
satisfied at the time with Google's presented documentation and
migration plan, it would be unreasonable for us to retroactively censure
Google for following that plan.

On 09/02/17 22:55, Peter Bowen wrote:
> Policy Suggestion A) When transferring a root that is EV enabled, it
> should be clearly stated whether the recipient of the root is also
> receiving the EV policy OID(s).

I agree with this suggestion; we should update
https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually
incorporate it into the main policy when we fix
https://github.com/mozilla/pkipolicy/issues/57 .

> I think that this is the key issue. In my reading, "root
> certificates" are not members of the program. Rather organizations
> (legal entities) are members and each member has some number of root
> certificates.
>
> Google was not a member of the program and had not applied to be a
> member of the program at the time they received the roots already in
> the program. This seems problematic to me.

https://wiki.mozilla.org/CA:RootTransferPolicy says that "The
organization who is transferring ownership of the root certificate’s
private key must ensure that the transfer recipient is able to fully
comply with Mozilla’s CA Certificate Policy. The original organization
will continue to be responsible for the root certificate's private key
until the transfer recipient has provided Mozilla with their Primary
Point of Contact, CP/CPS documentation, and audit statement (or opinion
letter) confirming successful transfer of the root certificate and key."

I would say that an organization which has acquired a root certificate
in the program and which has provided Mozilla with the above-mentioned
information is thereby a member of the program. As the policy says that
the transferring entity continues to be responsible until the
information is provided, that seems OK to me.

This position would logically lead to the position that a root inclusion
request from an organization which does not have any roots is also,
implicitly, an application to become a member of the program but the two
things are distinct. One can become a member of the program in other
ways. Membership is sort of something that happens to one automatically
when one successfully achieves ownership of an included root.

> Policy Suggestion B) Require that any organization wishing to become
> a member of the program submit a bug with links to content
> demonstrating compliance with the Mozilla policy. Require that this
> be public prior to taking control of any root in the program.

We do require this, but not publicly. I note and recognise Ryan's
concern about requiring advance disclosure of private deals. I could see
a requirement that a transferred root was not allowed to issue anything
until the appropriate paperwork was publicly in place. Would that be
suitable?

> Policy Suggestion C) Recognize that root transfers are distinct from
> the acquisition of a program member. Acquisition of a program
> member (meaning purchase of the company) is a distinctly different
> activity from moving only a private key, as the prior business
> controls no longer apply in the latter case.

https://wiki.mozilla.org/CA:RootTransferPolicy does make this
distinction, I feel - how could it be better made?

> Policy Suggestion D) Moving from being a RA to a CA or moving from
> being a single tier/online (i.e. Subordinate-only) CA to being a
> multi-tier/root CA requires a PITRA

Again, would this be covered by a requirement that no issuance was
permitted from a transferred root until all the paperwork was in place,
including appropriately-scoped audits? This might lead to a PITRA, but
would not have to.

Gerv

[Jakob Bohm]

On 08/03/2017 16:54, Gervase Markham wrote:
> On 08/03/17 03:54, Peter Kurrasch wrote:
>> - Google has acquired 2 root certificates from GMO GlobalSign but not
>> the ‎company itself.
>
> Yes.
>
>> GMO GlobalSign will continue to own other roots and
>> will use only those other roots for the various products and services
>> they choose to offer going forward.
>
> Not quite. GMO GlobalSign continues to control some subCAs of the roots
> it sold to Google, and is using those (presumably) to wind down its
> interest in those roots over time or support customer migrations to
> other roots. This happens to include issuing EV certificates.
>

An open question is how revocation and OCSP status for the
existing intermediaries issued by the acquired roots is handled.

For example, does GTS or GlobalSign run active OCSP servers at the URLs
listed in the AIA of the GlobalSign operated non-expired intermediaries
that positively confirm the validity of each of those intermediaries?

Does GTS sign regularly updated CRLs published at the (GlobalSign) URLs
listed in the CRL URL extensions in the GlobalSign operated non-expired
intermediaries?

Hopefully these things are answered somewhere in the GTS CP/CPS for the
acquired roots.


>> ...
> ...

>
>> - The GlobalSign web site has no mention of this acquisition for reasons
>> which are unknown.
>
> Why would this be a requirement by anyone?

Any relying party seeing the existing root in a chain would see the
name GlobalSign in the Issuer DN and naturally look to GlobalSign's
website and CP/CPS for additional information in trying to decide if
the chain should be trusted.

A relying party might assume, without detailed checks, that these roots
are operated exclusively by GlobalSign in accordance with GlobalSign's
good reputation.

Thus a clear notice that these "GlobalSign roots" are no longer
operated by GlobalSign at any entrypoint where a casual relying party
might go to check who "GlobalSign R?" is would be appropriate.

If possible, making Mozilla products present these as "Google", not
"GlobalSign" in short-form UIs (such as the certificate chain tree-like
display element). Similarly for other root programs (for example, the
Microsoft root program could change the "friendly name" of these).

>
>> Further, the web site does not make their CP/CPS
>> documents readily available
>
> Which website? The CP/CPS documents for which root(s)?
>
> The GTS CP and CPS are here: http://pki.goog/.
>
>> - A relying party who takes the initiative to review a certificate chain
>> that goes up to either of the acquired roots will see that it is
>> anchored (or "verified by") GlobalSign. No mention of Google will be
>> made anywhere in the user interface.
>
> I would expect there to be intermediate certificates with Google's name
> in; it's not permitted to issue EE certs directly from a root. However,
> neither GlobalSign's nor Google's name would appear in primary UI in
> Firefox, as we don't display CA names.

At least in one Mozilla-based browser, the UI shows the name of the
Intermediary as a tooltip, not of the root. So OK for this case.

[Ryan Hurst]

> pzb: According to the opinion letter:

> "followed the CA key generation and security requirements in its:

> Google Internet Authority G2 CPS v1.4" (hyperlink omitted)

> According to that CPS, "Key Pairs for the Google Internet Authority
> are generated and installed in accordance with the contract between
> Google and GeoTrust, Inc., the Root CA."

> Are you asserting that the authority for the key generation process

> the new Google roots is "the contract between Google and GeoTrust,
> Inc."?

No, that is not the intent of that statement, it is a good catch. This is simply a poorly worded statement.

To clarify our acquisition of these keys and certificates are independent of our agreement with GeoTrust, Inc.

The Intent of that statement is to say that the technical requirements of that contract, which in essence refer to meeting the WebTrust requirements, were followed.

[Ryan Hurst]

> jacob: Could a reasonably condition be that decision authority, actual and

> physical control for a root are not moved until proper root program
> coordination has been done (an action which may occur after/before the
> commercial conclusion of a transaction). From a business perspective
> this could be comparable to similar requirements imposed on some
> physical objects that can have public interest implications.

Microsoft has a similar requirement in their program, we had to get permission
from them before we could finalize commercial terms for this acquisition.
I personally think this is a good policy and one I think Mozilla should adopt as well.

It adds more complexity to these acquisitions in that one needs to get the approvals
from multiple parties but I think that the value to the ecosystem warrants
this complexity.


> Jacob: For clarity could Google and/or GTS issue a dedicated CP/CPS pair for

> the brief period where Google (not GTS) had control of the former
> GlobalSign root (such a CP/CPS would be particularly simple given that
> no certificates were issued). Such as CP/CPS should also clarify any
> practices and procedures for signing revocation related data (CRLs,
> OCSP responses, OCSP responder certificates) from that root during the
> transition. The CP/CPS would also need to somehow state that the
> former GlobalSign issued certificates remain valid, though no further
> such certificates were issued in this interim period.

> Similarly could Google and/or GTS issue a dedicated CP/CPS pair for the

> new roots during the brief period where Google (not GTS) had control of
> those new roots.

While we want to work with the community to provide assurances we followed
best practices and the required policies in this transfer I do not think this would provide
any further insights.

Before the transfer we, and our auditors, reviewed the CP/CPS, as well as the policies
and procedures associated with the the management of these keys, and found them to be
both compliant with both the requirements and best practices. In other words,
both we, and our auditors, are stating, as supported by the opinion letter, that we believe the
Google CP/CPS covered these keys during this period.

If we created a new CP/CPS for that period it would, at best, be a subset of the
Google CP/CPS and offer no new information other than the omission of a few details.

Could you maybe clarify what your goals are with this request, with that we can potentially
propose an alternate approach to address those concerns.


[Ryan Hurst]

Gerv has already responded and while his response is correct I have a little more detail I can share, see bellow.

> Peter Kurrash: I'm trying to keep score here but am having difficulties. Can someone confirm if

> the following statements are correct:

> - Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself.

Correct, two root certificates and their keys were acquired.


> Peter Kurrash: GMO GlobalSign will continue to own other roots and will use only those other roots for
> the various products and services they choose to offer going forward. There is no affiliation or business

> relationship between GMO GlobalSign and Google after the completion of the acquisition.

Mostly correct, we do have a contractual obligation to GMO GlobalSign relative to the subordinate that exists under GlobalSign R2, that subordinate is owned and operated by GMO GlobalSign. The terms of this agreement require us to provide revocation services while they migrate their customers off. It also requires them to maintain their WebTrust accreditation.

I must also add that Google is large organization and may now, or in the future, have other agreements with GMO GlobalSign but I can say those agreements would likely be orthogonal to this transaction.


> Peter Kurrash:No public announcement of the acquisition was made prior to January 26, 2017

> via the Google security blog.

No, this is not correct, the first public announcement was at the CAB/Forum in mid October 2016 and the second was the Mozilla bug database on December 22nd, 2016.

> Peter Kurrash: No disclosure has been made regarding what specific items were acquired,

> including such things as: "private key material" (HSM's and whatnot); computer equipment used
> as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure
> used in the operations and maintenance of the acquired roots; data such as subscriber lists,
> databases, server logs, payment details and histories, certificate issuance activities and histories,
> etc.; any access rights to physical space such as offices, data centers, development and test
> facilities, and so forth; and last, but not least, any personnel, documentation, training materials,

> or other knowledge products. That is correct, we did not enumerate the items involved in the exchange.

The auditor's opinion letter covering the transfer is the most explicit public document covering the transfer.

I can say that the acquisition included the acquisition of the root key material and corresponding certificates. Additionally the transfer included tooling, documentation and training related to the aforementioned assets. The elements included were within the scope necessary to enable us to satisfy auditors of proper historical and future management of the associated keys.

For those who are interested I can also add we did not purchase the GMO GlobalSign HSMs, instead we purchased our own HSMs directly from the manufacturer. These HSMs were compatible with what were in use by GMO GlobalSign and we utilized the key migration capabilities of those devices to migrate those keys to our HSMs.

> Peter Kurrash: The scope of impact to existing GlobalSign customers is not known. Neither

> GMO GlobalSign nor Google have notified any existing clients of the acquisition.

I can not speak for GMO GlobalSign or what GMO GlobalSign has or has not told affected customers, that said I do know that they have updated their CP/CPS.

I can say that our key migration plan was chosen, in part, to provide GMO GlobalSign enough time to migrate affected customers to CAs operated under their other roots.

> Peter Kurrash: The GlobalSign web site has no mention of this acquisition for reasons which are
> unknown. Further, the web site does not make their CP/CPS documents readily available limiting the

> ability for current subscribers and relying parties to decide if continued use of a cert chaining up to > these roots is acceptable to them.

I can not speak for GMO GlobalSign or what GMO GlobalSign has or has not done, however a Google search of “GlobalSign CPS” has the first match of https://www.globalsign.com/en/repository/ which has their CP/CPS.

Additionally I am not aware of a requirement to do notification, I would only expect notification if it materially impacted them and I personally would argue that since GMO GlobalSign continues to operate many other roots as well as the related sub CA there is not a material impact.


> Peter Kurrash: A relying party who takes the initiative to review a certificate chain that goes up to either

> of the acquired roots will see that it is anchored (or "verified by") GlobalSign. No mention of Google will > be made anywhere in the user interface.

GMO GlobalSign continues to maintain an active WebTrust audit for the CA under R2. As the operator of the issuing CA, they are responsible for the verification of of the identity of the associated certificates. This includes those certificates they have historically issued as well as those they may issue in the future, given this, the above this statement is accurate.

Additionally it is also common for the name of the root not to match who is the current operator, for example in the 90s I created several roots for a company called ValiCert. Those roots have changed hands several times.

I can also say that the intent is for GMO GlobalSign to migrate existing customers off of this subordinate CA to one issued under one of their roots as soon as practical.


> Peter Kurrash: Google has acquired these roots in order to better serve their subscribers, which are
> organizations (not people) throughout the many Google companies. Relying parties (i.e. end users of

> the various Google products) are not affected positively or negatively by this acquisition.

Mostly true, though we have no product plans to disclose at this time we may, in the future issue certificates to people as well as to organizations outside of Google.


> Peter Kurrash: Mozilla granted Google's request to keep the acquisition confidential based on
> statements made by Google and Google's auditor E&Y. Neither GlobalSign nor their auditors offered

> any opinion on this matter.

Mostly true, both GMO GlobalSign and Google independently and together reached out to the respective root programs both before, during and after the transfer.

I can say the negotiation and execution of commercial contracts are commonly covered under nondisclosure agreements as are engagements with consultants and auditors. As such I would not expect in this, or in any other commercial negotiation for the parties involved to make public opinion statements about confidentiality.

[Ryan Hurst]

> pzb: Policy Suggestion A) When transferring a root that is EV enabled, it

> should be clearly stated whether the recipient of the root is also
> receiving the EV policy OID(s).

> Gerv: I agree with this suggestion; we should update

> https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually
> incorporate it into the main policy when we fix
> https://github.com/mozilla/pkipolicy/issues/57 .

I think this is good.


> Gerv: https://wiki.mozilla.org/CA:RootTransferPolicy says that "The

> organization who is transferring ownership of the root certificate’s
> private key must ensure that the transfer recipient is able to fully
> comply with Mozilla’s CA Certificate Policy. The original organization
> will continue to be responsible for the root certificate's private key
> until the transfer recipient has provided Mozilla with their Primary
> Point of Contact, CP/CPS documentation, and audit statement (or opinion
> letter) confirming successful transfer of the root certificate and key."

> Gerv: I would say that an organization which has acquired a root certificate

> in the program and which has provided Mozilla with the above-mentioned
> information is thereby a member of the program. As the policy says that
> the transferring entity continues to be responsible until the
> information is provided, that seems OK to me.

This seems reasonable to me also.

> Gerv: This position would logically lead to the position that a root inclusion

> request from an organization which does not have any roots is also,
> implicitly, an application to become a member of the program but the two
> things are distinct. One can become a member of the program in other
> ways. Membership is sort of something that happens to one automatically
> when one successfully achieves ownership of an included root.

This seems reasonable to me also.


> pzb: Policy Suggestion B) Require that any organization wishing to become

> a member of the program submit a bug with links to content
> demonstrating compliance with the Mozilla policy. Require that this
> be public prior to taking control of any root in the program.

> Gerv: We do require this, but not publicly. I note and recognise Ryan's

> concern about requiring advance disclosure of private deals. I could see
> a requirement that a transferred root was not allowed to issue anything
> until the appropriate paperwork was publicly in place. Would that be
> suitable?

Could you clarify what you mean by appropriate paperwork?


> pzb: Policy Suggestion C) Recognize that root transfers are distinct from

> the acquisition of a program member. Acquisition of a program
> member (meaning purchase of the company) is a distinctly different
> activity from moving only a private key, as the prior business
> controls no longer apply in the latter case.

> Gerv: https://wiki.mozilla.org/CA:RootTransferPolicy does make this

distinction, I feel - how could it be better made?

After re-reading this text I personally think this is clear.


> pzb: Policy Suggestion D) Moving from being a RA to a CA or moving from

> being a single tier/online (i.e. Subordinate-only) CA to being a
> multi-tier/root CA requires a PITRA

> Gerv: Again, would this be covered by a requirement that no issuance was

> permitted from a transferred root until all the paperwork was in place,
> including appropriately-scoped audits? This might lead to a PITRA, but
> would not have to.

This seems reasonable to me also.

[Ryan Hurst]

> Jakob: An open question is how revocation and OCSP status for the

> existing intermediaries issued by the acquired roots is handled.

Google is responsible for producing CRLs for from these roots. We are also currently
relying on the OCSP responder infrastructure of GlobalSign for this root but are
In the process of migrating that inhouse.

> Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) URLs

> listed in the CRL URL extensions in the GlobalSign operated non-expired
> intermediaries?

At this time Google produces CRLs and works with GlobalSign to publish those CRLs.

> Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for the
> acquired roots.

This level of detail is not typically included in a CPS, for example, a service may change
Which internet service provider or CDN service they use and not need update their CP/CPS.


> Jakob: Any relying party seeing the existing root in a chain would see the

> name GlobalSign in the Issuer DN and naturally look to GlobalSign's
> website and CP/CPS for additional information in trying to decide if
> the chain should be trusted.

The GlobalSign CPS indicates that the R2 and R4 are no longer under their control.

Additionally given the long term nature of CA keys, it is common for the DN not to accurately
represent the organization that controls it. As I mentioned in an earlier response in the 90’s I
created roots for a company called Valicert that has changed hands several times, additionally
Verisign, now Symantec in this context has a long history of acquiring CAs and as such they
have CA certificates with many different names within them.

> Jakob: A relying party might assume, without detailed checks, that these roots

> are operated exclusively by GlobalSign in accordance with GlobalSign's
> good reputation.

As the former CTO of GlobalSign I love hearing about their good reputation ;)

However I would say the CP/CPS is the authoritative document here and since
GMO GlobalSign CP/CPS clearly states the keys are no longer in their control I believe this
Should not be an issue.

> Jakob: Thus a clear notice that these "GlobalSign roots" are no longer

> operated by GlobalSign at any entrypoint where a casual relying party
> might go to check who "GlobalSign R?" is would be appropriate.

I would argue the CA’s CP/CPS’s are the authoritative documents here and would
Satisfy this requirement.

> Jakob: If possible, making Mozilla products present these as "Google", not

> "GlobalSign" in short-form UIs (such as the certificate chain tree-like
> display element). Similarly for other root programs (for example, the
> Microsoft root program could change the "friendly name" of these).

I agree with Jakob here, given the frequency in which roots change hands, it would make
sense to have an ability to do this. Microsoft maintains this capability that is made available
to the owner.

There are some limitations relative to where this domain information is used, for example
in the case of an EV certificate, if Google were to request Microsoft use this capability the
EV badge would say verified by Google. This is because they display the root name for the
EV badge. However, it is the subordinate CA in accordance with its CP/CPS that is responsible
for vetting, as such the name displayed in this case should be GlobalSign.

Despite these limitations, it may make sense in the case of Firefox to maintain a similar capability.

[Ryan Sleevi]

On Wed, Mar 8, 2017 at 1:02 PM, Ryan Hurst via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> There are some limitations relative to where this domain information is
> used, for example
> in the case of an EV certificate, if Google were to request Microsoft
> use this capability the
> EV badge would say verified by Google. This is because they display the
> root name for the
> EV badge. However, it is the subordinate CA in accordance with its CP/CPS
> that is responsible
> for vetting, as such the name displayed in this case should be GlobalSign.
>
> Despite these limitations, it may make sense in the case of Firefox to
> maintain a similar capability.

Outside of EV, can you articulate why (preferably in a dedicated thread)

There have been requests over the years from a variety of CAs for this.
Each time, they've been rejected. If there's new information at hand, or a
better understanding of the landscape since then, it would be good to
articulate why, specifically for Mozilla products :)

[ad...@peculiarventures.com]

> Outside of EV, can you articulate why (preferably in a dedicated thread)

> There have been requests over the years from a variety of CAs for this.
> Each time, they've been rejected. If there's new information at hand, or a
> better understanding of the landscape since then, it would be good to
> articulate why, specifically for Mozilla products :)

Outside EV I think it would be very hard to make the case, though Mozilla does maintain a certificate viewer that is easily accessible I have to imagine it is almost never used. As such, in the case of DV I think it would not make much sense.

[Richard Wang]

As I understand, the EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, so the root key transfer doesn't have the EV OID transfer case, CA can't transfer its own EV OID to other CA exception the CA is full acquired.

So the policy can make clear that the root key transfer can't transfer the EV OID, the receiver must use its own EV policy OID for its EV SSL, the receiver can't use the transferor's EV OID.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, March 9, 2017 12:21 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Google Trust Services roots

Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions.

Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan, it would be unreasonable for us to retroactively censure Google for following that plan.

On 09/02/17 22:55, Peter Bowen wrote:

> Policy Suggestion A) When transferring a root that is EV enabled, it
> should be clearly stated whether the recipient of the root is also
> receiving the EV policy OID(s).

[Ryan Sleevi]

Hi Richard,

That's not how Certificate Policy OIDs work - either in the specifications
or in the Baseline Requirements. I'm also not aware of any program
requiring what you describe.

Because of this, it's unclear to me, and I suspect many other readers, why
you believe this is the case, or if you meant that it SHOULD be the case
(for example, developing a new policy requirement), why you believe this.

Perhaps you could share more details about your reasoning?

[Richard Wang]

Maybe I don’t say it clearly.



The EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, right?

Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV OID is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6

And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no CABF EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1



What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID for its EV SSL.



So, no EV OID transfer issue for root key transfer.





Best Regards,



Richard

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, March 9, 2017 11:14 AM
To: Gervase Markham <ge...@mozilla.org>; Richard Wang <ric...@wosign.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Google Trust Services roots

Hi Richard,



That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what you describe.



Because of this, it's unclear to me, and I suspect many other readers, why you believe this is the case, or if you meant that it SHOULD be the case (for example, developing a new policy requirement), why you believe this.



Perhaps you could share more details about your reasoning?

On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:

As I understand, the EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, so the root key transfer doesn't have the EV OID transfer case, CA can't transfer its own EV OID to other CA exception the CA is full acquired.

So the policy can make clear that the root key transfer can't transfer the EV OID, the receiver must use its own EV policy OID for its EV SSL, the receiver can't use the transferor's EV OID.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosig...@lists.mozilla.org<mailto:wosig...@lists.mozilla.org>] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, March 9, 2017 12:21 AM
To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Google Trust Services roots

Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions.

Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan, it would be unreasonable for us to retroactively censure Google for following that plan.

On 09/02/17 22:55, Peter Bowen wrote:
> Policy Suggestion A) When transferring a root that is EV enabled, it
> should be clearly stated whether the recipient of the root is also
> receiving the EV policy OID(s).

I agree with this suggestion; we should update https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it into the main policy when we fix
https://github.com/mozilla/pkipolicy/issues/57 .


_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

Well, you still said the same thing, and I understood what you said, but
not why you said it or why you believe it. That's why I was asking for new
details.

Certificate Policy OIDs don't say who the certificate belongs to or who
issued the certificate. They describe the policies relative to how the
certificate was issued and validated. This is much clearer if you read the
relevant ETSI TS/EN series of docs related to Certificate Policies.

To your point about identifying the issuer, I may be misunderstanding your
point, but it sounds like you're just confused about how browsers work.
Browsers don't look up the EV OID to determine who the issuer is, so if
you're concerned that would present a problem, it doesn't.

Instead, browsers look for *any* EV enabled OID in the leaf certificate,
then attempt to build/verify that a chain can be built to one or more root
certificates "enabled" for that OID. If they can, the leaf is called EV,
and the browser determines who issued it by looking at the root.

So if Symantec were to issue such a certificate using GlobalSign's EV OID,
and Symantec's root was enabled for that OID, and it validated according to
RFC5280 for that OID, then the certificate would appear as a
Symantec-issued (because Symantec root) EV cert.

Of course, I have oversimplified this for you - the actual UI browsers tend
to take is not from the root, but from the issuing intermediate, or
metadata external to the root, so it's also not an issue for the root to
say Symantec, ValiCert, Equifax, Norton, or something else - because that's
ignored when better data is available, and it always is, if the CA is
responsive to root program requirements.

On Wed, Mar 8, 2017 at 10:31 PM Richard Wang <ric...@wosign.com> wrote:

> Maybe I don’t say it clearly.
>
>
>
> The EV SSL have two policy OID, one is the CABF EV OID, another one is the
> CA's EV OID, right?
>

> Check the EV SSL for www.symantec.com, the CABF EV OID is 2.23.140.1.1,

> and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6
>

> And check www.gloabalsign.com EV SSL that no CABF EV OID, GlobalSign EV

> OID is 1.3.6.1.4.1.4146.1.1
>
>
>
> What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to
> GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign,
> so Google can’t use this EV OID for its own EV SSL, Google must use its own
> EV OID for its EV SSL.
>
>
>
> So, no EV OID transfer issue for root key transfer.
>
>
>
>
>
> Best Regards,
>
>
>
> Richard
>
>
>

> *From:* Ryan Sleevi [mailto:ry...@sleevi.com]
> *Sent:* Thursday, March 9, 2017 11:14 AM
> *To:* Gervase Markham <ge...@mozilla.org>; Richard Wang <ric...@wosign.com>;
> mozilla-dev-s...@lists.mozilla.org
>
>
> *Subject:* Re: Google Trust Services roots

>
>
>
> Hi Richard,
>
>
>
> That's not how Certificate Policy OIDs work - either in the specifications
> or in the Baseline Requirements. I'm also not aware of any program
> requiring what you describe.
>
>
>
> Because of this, it's unclear to me, and I suspect many other readers, why
> you believe this is the case, or if you meant that it SHOULD be the case
> (for example, developing a new policy requirement), why you believe this.
>
>
>
> Perhaps you could share more details about your reasoning?
>
>
>
> On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy <

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

[Richard Wang]

I don’t think so, please check this page: https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. So, as I understand that the browser display EV green bar and display the “Identified by CA name” is based on this CA’s EV OID.



I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV SSL using GlobalSign's EV OID, I think IE browser will display this EV SSL is identified by GlobalSign, not by Symantec.

Best Regards,



Richard



From: Ryan Sleevi [mailto:ry...@sleevi.com]

Sent: Thursday, March 9, 2017 12:21 PM
To: Gervase Markham <ge...@mozilla.org>; Richard Wang <ric...@wosign.com>; Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Google Trust Services roots

Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details.



Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate. They describe the policies relative to how the certificate was issued and validated. This is much clearer if you read the relevant ETSI TS/EN series of docs related to Certificate Policies.



To your point about identifying the issuer, I may be misunderstanding your point, but it sounds like you're just confused about how browsers work. Browsers don't look up the EV OID to determine who the issuer is, so if you're concerned that would present a problem, it doesn't.



Instead, browsers look for *any* EV enabled OID in the leaf certificate, then attempt to build/verify that a chain can be built to one or more root certificates "enabled" for that OID. If they can, the leaf is called EV, and the browser determines who issued it by looking at the root.



So if Symantec were to issue such a certificate using GlobalSign's EV OID, and Symantec's root was enabled for that OID, and it validated according to RFC5280 for that OID, then the certificate would appear as a Symantec-issued (because Symantec root) EV cert.



Of course, I have oversimplified this for you - the actual UI browsers tend to take is not from the root, but from the issuing intermediate, or metadata external to the root, so it's also not an issue for the root to say Symantec, ValiCert, Equifax, Norton, or something else - because that's ignored when better data is available, and it always is, if the CA is responsive to root program requirements.





On Wed, Mar 8, 2017 at 10:31 PM Richard Wang <ric...@wosign.com<mailto:ric...@wosign.com>> wrote:

Maybe I don’t say it clearly.



The EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, right?

Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV OID is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6

And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no CABF EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1

What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID for its EV SSL.



So, no EV OID transfer issue for root key transfer.





Best Regards,



Richard

From: Ryan Sleevi [mailto:ry...@sleevi.com<mailto:ry...@sleevi.com>]
Sent: Thursday, March 9, 2017 11:14 AM

To: Gervase Markham <ge...@mozilla.org<mailto:ge...@mozilla.org>>; Richard Wang <ric...@wosign.com<mailto:ric...@wosign.com>>; mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>


Subject: Re: Google Trust Services roots

Hi Richard,



That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what you describe.



Because of this, it's unclear to me, and I suspect many other readers, why you believe this is the case, or if you meant that it SHOULD be the case (for example, developing a new policy requirement), why you believe this.



Perhaps you could share more details about your reasoning?

On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:

As I understand, the EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, so the root key transfer doesn't have the EV OID transfer case, CA can't transfer its own EV OID to other CA exception the CA is full acquired.

So the policy can make clear that the root key transfer can't transfer the EV OID, the receiver must use its own EV policy OID for its EV SSL, the receiver can't use the transferor's EV OID.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosig...@lists.mozilla.org<mailto:wosig...@lists.mozilla.org>] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, March 9, 2017 12:21 AM
To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Google Trust Services roots

Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions.

Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan, it would be unreasonable for us to retroactively censure Google for following that plan.

On 09/02/17 22:55, Peter Bowen wrote:
> Policy Suggestion A) When transferring a root that is EV enabled, it
> should be clearly stated whether the recipient of the root is also
> receiving the EV policy OID(s).

I agree with this suggestion; we should update https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it into the main policy when we fix
https://github.com/mozilla/pkipolicy/issues/57 .


_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Bowen]

Richard,

I'm afraid a few things are confused here.

First, a single CA Operator may have multiple roots in the browser
trust list. Each root may list one or more certificate policies that
map to the EV policy. Multiple roots that follow the same policy may
use the same policy IDs and different roots from the same operator may
use different policies.

For example, I see the following in the Microsoft trust list:

CN=CA 沃通根证书,O=WoSign CA Limited,C=CN
CN=Class 1 Primary CA,O=Certplus,C=FR
CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN
CN=CA WoSign ECC Root,O=WoSign CA Limited,C=CN
CN=Certification Authority of WoSign G2,O=WoSign CA Limited,C=CN
each of these has one EV mapped policy: 1.3.6.1.4.1.36305.2

CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.1 mapped to EV
CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.2 mapped to EV
CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.3 mapped to EV
CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.4 mapped to EV
All of these are from the same company but each has their own policy identifier.

The information on "Identified by <something>" in Microsoft's browsers
comes from the "Friendly Name" field in the trust list. For example
the friendly name of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign
1999".

For something like the AffirmTrust example, they could easily sell one
root along with the exclusive right to use that root's EV OID without
impacting their other OIDs.

Does that make sense?

Thanks,
Peter

[Richard Wang]

Why we setup one EV OID for all roots is that we use the same policy for all EV SSL certificate no matter it is issued by which root. The policy OID is unique ID

If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, this means two companies use the same policy?

It is better to do a test: Google issue a EV SSL certificate from this acquired root using the GlobalSign EV OID, then check every browser's UI display info, to check if that info will confuse the browser users.

Best Regards,

Richard

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Thursday, March 9, 2017 1:11 PM
To: Richard Wang <ric...@wosign.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; Gervase Markham <ge...@mozilla.org>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Google Trust Services roots

[Kurt Roeckx]

On 2017-03-09 05:21, Ryan Sleevi wrote:
> Well, you still said the same thing, and I understood what you said, but
> not why you said it or why you believe it. That's why I was asking for new
> details.
>
> Certificate Policy OIDs don't say who the certificate belongs to or who
> issued the certificate. They describe the policies relative to how the
> certificate was issued and validated. This is much clearer if you read the
> relevant ETSI TS/EN series of docs related to Certificate Policies.
>
> To your point about identifying the issuer, I may be misunderstanding your
> point, but it sounds like you're just confused about how browsers work.
> Browsers don't look up the EV OID to determine who the issuer is, so if
> you're concerned that would present a problem, it doesn't.
>
> Instead, browsers look for *any* EV enabled OID in the leaf certificate,
> then attempt to build/verify that a chain can be built to one or more root
> certificates "enabled" for that OID. If they can, the leaf is called EV,
> and the browser determines who issued it by looking at the root.

I would also like to see that all EV certificates actually have the CABF
EV OID, possibly in addition to any CA specific OID. I would actually
like to see that for all CABF OIDs, it's currently only required for the
IV certificates as far as I know.


Kurt

[Gervase Markham]

On 08/03/17 17:43, Ryan Hurst wrote:
>> Gerv: We do require this, but not publicly. I note and recognise Ryan's
>> concern about requiring advance disclosure of private deals. I could see
>> a requirement that a transferred root was not allowed to issue anything
>> until the appropriate paperwork was publicly in place. Would that be
>> suitable?
>
> Could you clarify what you mean by appropriate paperwork?

Mozilla requires that roots in our program have certain paperwork in
place in order to be issuing certs. We need the organization to publish
a CP and CPS which relate to the root, and we need audits (ongoing or
PITRA), and so on. That's what I mean.

Gerv

[Gervase Markham]

On 09/03/17 02:15, Richard Wang wrote:
> So the policy can make clear that the root key transfer can't
> transfer the EV OID, the receiver must use its own EV policy OID for
> its EV SSL, the receiver can't use the transferor's EV OID.

We could indeed write this into the policy, but it would have the effect
of stopping the receiver of the root from issuing EV certs until the
updated root store with the new policy OID mapping was in all Firefoxes.
Given that OIDs are just opaque identifiers, it seems unnecessary to
require this.

What security or other problem is caused if e.g. Google were to use an
EV OID originally used by (or still used by) GlobalSign, assuming the
two companies agreed that was OK?

Gerv

[Ryan Sleevi]

Yes, it means the two companies used the same policy for issuance - as
identified by that policy. Did you read the ETSI materials I suggested you
do? Perhaps this would make it easier for you.

I don't think encouraging a CA to misissue - which if you read other
people's replies, you would see Ryan identified it as misissuance (but not
for the reasons you note), is productive. Misissuing is very bad, as you
hopefully know.

If two certificates, from different organizations, have the same policy
OID, it means they were issued in whatever manner necessary to comply with
that OID at the time they were issued. And that's perfectly ok and not at
all prohibited.

If your worried that GlobalSign's policy might describe GlobalSign-only
things, then you're forgetting GlobalSign can update their policy at any
time. Just like we use the same CABF EV OID despite the policies for EV
changing every time we update the EVG, at any point GlobalSign could
indicate their EV OID "just" means following the EVGs, which any
organization that is trusted to issue certificates can do at any time.

On Thu, Mar 9, 2017 at 1:14 AM Richard Wang via dev-security-policy <

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Richard Wang]

As my understanding, if WoSign buy an trusted EV enabled root key with EV OID today, then we can issue WoSign EV SSL cert using this EV OID tomorrow, the browser will display EV green bar. Right?
If right, we like this policy, thanks.

Best Regards,

Richard

> On 9 Mar 2017, at 19:51, Gervase Markham <ge...@mozilla.org> wrote:
>
>> On 09/03/17 02:15, Richard Wang wrote:

>> So the policy can make clear that the root key transfer can't
>> transfer the EV OID, the receiver must use its own EV policy OID for
>> its EV SSL, the receiver can't use the transferor's EV OID.
>

[Gervase Markham]

On 09/03/17 12:38, Richard Wang wrote:
> As my understanding, if WoSign buy an trusted EV enabled root key
> with EV OID today, then we can issue WoSign EV SSL cert using this EV
> OID tomorrow, the browser will display EV green bar. Right?

Technically, you are correct - such certs would produce the EV UI.
However, if you didn't have an EV audit which covered the root, your
root would quickly get kicked out of the root programs.

Gerv

[Richard Wang]

Clear, thanks.

Best Regards,

Richard

> On 9 Mar 2017, at 22:05, Gervase Markham via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>> On 09/03/17 12:38, Richard Wang wrote:

>> As my understanding, if WoSign buy an trusted EV enabled root key
>> with EV OID today, then we can issue WoSign EV SSL cert using this EV
>> OID tomorrow, the browser will display EV green bar. Right?
>

> Technically, you are correct - such certs would produce the EV UI.
> However, if you didn't have an EV audit which covered the root, your
> root would quickly get kicked out of the root programs.
>
> Gerv

[Jakob Bohm]

This was merely suggested as a possible way to formally answer the
fears and questions posed by others about the situation during the
transition and the discussed inapplicability of some wording in the
old Google CP/CPS to the new situation.

[Peter Kurrasch]

By definition, a CPS is the authoritative document on what root
certificates a CA operates and how they go about that operation. If the
GlobalSign CPS has been updated to reflect the loss of their 2 roots,
that's fine. Nobody is questioning that.

What is being questioned is whether updating the GlobalSign CPS is
sufficient to address the needs, concerns, questions, or myriad other
issues that are likely to come up in the minds of GlobalSign subscribers
and relying parties--and, for that matter, Google's own subscribers and
relying parties. To that, I think the answer must be: "no, it's not
enough". Most people on the internet have never heard of a CPS and of
those who have, few will have ever read one and fewer still will have read
the GlobalSign CPS.

It would be good if you could elaborate more on what steps Google will be
taking to communicate to the general public that GlobalSign means
GlobalSign except when it means Google and that sometimes Google will mean
GlobalSign as well.



On Wed, Mar 8, 2017 at 12:02 PM, Ryan Hurst via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > Jakob: An open question is how revocation and OCSP status for the

> > existing intermediaries issued by the acquired roots is handled.
>

> Google is responsible for producing CRLs for from these roots. We are also
> currently
> relying on the OCSP responder infrastructure of GlobalSign for this root
> but are
> In the process of migrating that inhouse.
>

> > Jakob: Does GTS sign regularly updated CRLs published at the

> (GlobalSign) URLs
> > listed in the CRL URL extensions in the GlobalSign operated non-expired
> > intermediaries?
>

> At this time Google produces CRLs and works with GlobalSign to publish
> those CRLs.
>

> > Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS
> for the
> > acquired roots.
>

> This level of detail is not typically included in a CPS, for example, a
> service may change
> Which internet service provider or CDN service they use and not need
> update their CP/CPS.
>
>

> > Jakob: Any relying party seeing the existing root in a chain would see

> the
> > name GlobalSign in the Issuer DN and naturally look to GlobalSign's
> > website and CP/CPS for additional information in trying to decide if
> > the chain should be trusted.
>

> The GlobalSign CPS indicates that the R2 and R4 are no longer under their
> control.
>
> Additionally given the long term nature of CA keys, it is common for the
> DN not to accurately
> represent the organization that controls it. As I mentioned in an earlier
> response in the 90’s I
> created roots for a company called Valicert that has changed hands several
> times, additionally
> Verisign, now Symantec in this context has a long history of acquiring CAs
> and as such they
> have CA certificates with many different names within them.
>

> > Jakob: A relying party might assume, without detailed checks, that these

> roots
> > are operated exclusively by GlobalSign in accordance with GlobalSign's
> > good reputation.
>

> As the former CTO of GlobalSign I love hearing about their good reputation
> ;)
>
> However I would say the CP/CPS is the authoritative document here and since
> GMO GlobalSign CP/CPS clearly states the keys are no longer in their
> control I believe this
> Should not be an issue.
>

> > Jakob: Thus a clear notice that these "GlobalSign roots" are no longer

> > operated by GlobalSign at any entrypoint where a casual relying party
> > might go to check who "GlobalSign R?" is would be appropriate.
>

> I would argue the CA’s CP/CPS’s are the authoritative documents here and
> would
> Satisfy this requirement.
>

> > Jakob: If possible, making Mozilla products present these as "Google",

> not
> > "GlobalSign" in short-form UIs (such as the certificate chain tree-like
> > display element). Similarly for other root programs (for example, the
> > Microsoft root program could change the "friendly name" of these).
>

> I agree with Jakob here, given the frequency in which roots change hands,
> it would make
> sense to have an ability to do this. Microsoft maintains this capability
> that is made available
> to the owner.
>

> There are some limitations relative to where this domain information is
> used, for example
> in the case of an EV certificate, if Google were to request Microsoft
> use this capability the
> EV badge would say verified by Google. This is because they display the
> root name for the
> EV badge. However, it is the subordinate CA in accordance with its CP/CPS
> that is responsible
> for vetting, as such the name displayed in this case should be GlobalSign.
>
> Despite these limitations, it may make sense in the case of Firefox to
> maintain a similar capability.

[Peter Bowen]

On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang <ric...@wosign.com> wrote:
> Why we setup one EV OID for all roots is that we use the same policy for all EV SSL certificate no matter it is issued by which root. The policy OID is unique ID
>
> If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, this means two companies use the same policy?
>
> It is better to do a test: Google issue a EV SSL certificate from this acquired root using the GlobalSign EV OID, then check every browser's UI display info, to check if that info will confuse the browser users.

Richard,

I'll make this easier:

Go to https://good.sca1a.amazontrust.com/ and
https://good.sca0a.amazontrust.com/ in Safari and Microsoft IE/Edge.
Tell me which CA issued the certificates for those sites. (Note that
we don't send SCTs on those sites right now, so they aren't treated as
EV in Chrome, and we are still pending for EV in Mozilla)

Thanks,
Peter

[Ryan Hurst]

On Thursday, March 9, 2017 at 9:00:21 PM UTC-8, Peter Kurrasch wrote:
> By definition, a CPS is the authoritative document on what root
> certificates a CA operates and how they go about that operation. If the
> GlobalSign CPS has been updated to reflect the loss of their 2 roots,
> that's fine. Nobody is questioning that.
>
> What is being questioned is whether updating the GlobalSign CPS is
> sufficient to address the needs, concerns, questions, or myriad other
> issues that are likely to come up in the minds of GlobalSign subscribers
> and relying parties--and, for that matter, Google's own subscribers and
> relying parties. To that, I think the answer must be: "no, it's not
> enough". Most people on the internet have never heard of a CPS and of
> those who have, few will have ever read one and fewer still will have read
> the GlobalSign CPS.

Again while I can not speak for GlobalSign I can say that there has been far
more public notice than a simple CP/CPS update.

In addition to the Google Blog post about the acquisition (https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html), the purchase was picked up by many high profile technology news sources, some of which included:
- https://www.theregister.co.uk/2017/01/27/google_root_ca/
- http://www.infoworld.com/article/3162102/security/google-moves-into-root-certificate-authority-business.html
- http://www.securityweek.com/google-launches-its-own-root-certificate-authority

Also this topic has been discussed at great length in numerous forums around the web.

This is above and beyond the public notification that is built into the various root programs such as:
> The Google Trust Services CP/CPs lists GlobalSign as subordinates
> The Google Trust Services website has a link to the GlobalSign CP/CPS as well as their audit reports.
> The Mozilla bug on this topic discusses the change in ownership,
> The Mozilla CA registry will also reference the change in ownership,
> The Microsoft CA registry will also reference the change in ownership,
> The Mozilla Salesforce instance will reference the change in ownership,
> This public thread discusses the change in ownership.

I am not sure there is much more meaningful options of notification left.

Additionally as stated, EV badges will still correctly reflect that it is GlobalSign who issues the associated certificates, and not Google.

The only opportunity for confusion comes from those who look at the certificates themselves and missed all of the above notifications.

It is also important to note that this is a very common situation, to see how common it is visit the page Microsoft maintains for Root Program members - https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx

You will notice the first column is the name of the current owner and the second column is the name in the certificate.

A few you will notice are:

Amazon, Starfield Services Root Certificate Authority - G2
Asseco Data Systems S.A. (previously Unizeto Certum), Certum CA
Entrust, Trend Micro 1
Entrust, Trend Micro 2
Entrust, Trend Micro 3
Entrust, Trend Micro 4
Comodo, The USERTrust Network™
Comodo, USERTrust (Client Authentication / Secure Email)
Comodo, USERTrust (Code Signing)
Comodo, USERTrust RSA Certification Authority
Comodo, UTN-USERFirst-Hardware
Symantec / GeoTrust
Symantec / Thawte
Symantec / VeriSign
Trustwave, XRamp Global Certification Authority

And more...

While I sincerely want to make sure there are no surprises, given how common it is for names in root certificates not to match the current owner, those who are looking at certificate chains should not be relying on the value in the root certificate in the first place wrong in very significant situations.

Ryan

[Richard Wang]

Good demo, thanks.

I checked that you are using Startfield EV OID in Startfield name root and in Amazon name root, means you are using the transferred root's EV OID. But I checked your CPS that don't state this point, please advise, thanks.

Best Regards,

Richard

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Friday, March 10, 2017 2:16 PM
To: Richard Wang <ric...@wosign.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; Gervase Markham <ge...@mozilla.org>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Google Trust Services roots

[Peter Bowen]

That is the Starfield Services EV policy identifier, not the Starfield
EV policy identifier. We clearly call out in section 1.1 of the our
CPS that Starfield Services Root Certificate Authority - G2 is covered
under the CPS.

[Jakob Bohm]

Those are all point-in-time news items, not pages that purport to be up
to date information of the current status when they are visited.

> Additionally as stated, EV badges will still correctly reflect that it is GlobalSign who issues the associated certificates, and not Google.
>
> The only opportunity for confusion comes from those who look at the certificates themselves and missed all of the above notifications.
>
> It is also important to note that this is a very common situation, to see how common it is visit the page Microsoft maintains for Root Program members - https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx
>
> You will notice the first column is the name of the current owner and the second column is the name in the certificate.
>
> A few you will notice are:
>
> Amazon, Starfield Services Root Certificate Authority - G2
> Asseco Data Systems S.A. (previously Unizeto Certum), Certum CA
> Entrust, Trend Micro 1
> Entrust, Trend Micro 2
> Entrust, Trend Micro 3
> Entrust, Trend Micro 4
> Comodo, The USERTrust Network™
> Comodo, USERTrust (Client Authentication / Secure Email)
> Comodo, USERTrust (Code Signing)
> Comodo, USERTrust RSA Certification Authority
> Comodo, UTN-USERFirst-Hardware
> Symantec / GeoTrust
> Symantec / Thawte
> Symantec / VeriSign
> Trustwave, XRamp Global Certification Authority
>
> And more...
>

Of all these, Starfield seems to be the only case where a single CA
name now refers to two different current CA operators (GoDaddy and
Amazon). All the others are cases of complete takeover. None are
cases where the name in the certificate is a still operating CA
operator, but the root is actually operated by a different entity
entirely.

Also, I don't see Google on that list.

> While I sincerely want to make sure there are no surprises, given how common it is for names in root certificates not to match the current owner, those who are looking at certificate chains should not be relying on the value in the root certificate in the first place wrong in very significant situations.
>
> Ryan
>

[Ryan Hurst]

> Of all these, Starfield seems to be the only case where a single CA
> name now refers to two different current CA operators (GoDaddy and
> Amazon). All the others are cases of complete takeover. None are
> cases where the name in the certificate is a still operating CA
> operator, but the root is actually operated by a different entity
> entirely.

That is true, but my point is that one can not rely on the name in root certificates, when certs are made to be good for well over a decade the concept of name continuity just doesn't hold.

> Also, I don't see Google on that list.

I noticed that too, Ill be reaching out to Microsoft to make sure its updated.

[Peter Kurrasch]

This is my second of three forks of this discussion on the transfer of 2 GlobalSign roots. This thread focuses on GMO GlobalSign because in my estimation they have put themselves in a precarious position that warrants public discussion. 

In previous comments I've made, I've expressed disapproval at the fact that there is no mention of the transfer on GlobalSign's website. I did not find it under News‎ and Events nor under the SSL sales pages nor under the Resources page. I also could find no information about the existence of different roots that GlobalSign has and their intended use cases.

The search result that Ryan H. mentions below is in fact a curious situation. A direct link to the CPS is listed, sure, but if you go to the ".../resources" page directly there is no mention of the CPS. I would assume that at some point a subscriber is required to accept the terms of the CPS and is then presented with an opportunity to obtain the actu‎al document, but what about the relying parties? Are relying parties allowed to obtain the document but only if they use a search engine to find it? Are we to expect that search engines will always and only return the correct version for the specific root in which I'm interested?

To be fair, I don't know that any of this constitutes a violation of any BR requirement or Mozilla policy--I assume not.‎ I also assume that GlobalSign is not the only offender in this regard. Still, I expect better than this from any root CA participant; surely a CA can give me something rather than leave me with nothing?

All that said, it is not even what causes me the most concern, which is the intermingling of the GlobalSign and ‎Google brands. Like it or not, there will always be questions like "Is this GlobalSign or is this Google?" and this creates a risk not only to GlobalSign but also the Internet community. (There is a risk to Google as well but I'll address that in a separate thread.)

The risk is a result of the confusion and uncertainty that are introduced by the transfer of these 2 roots.‎ Consider that right now I could launch a phishing campaign targeting GlobalSign subscribers with a message along the lines of "Did you know that GlobalSign has sold your certificate to Google? Click here to learn what you can do to protect your website." Should the person click on a link I might put the person on a fake login screen or a malware distribution point or engage in any other nefarious act of my choosing. For that matter I might try to sell the person my own certificate service: "Leave GlobalSign and Google behind! Protect the privacy of your website visitors and buy my service instead!"

The point here is that accuracy in my message is not needed. Instead, I can exploit the confusion and uncertainty (or, if you prefer, FUD) which can lead to damage to GlobalSign's reputation and possible loss of business. Conceivably this can also impact the global PKI if I'm able to gain unauthorized access to a subscriber's account and have certificates issued for my nefarious websites.

All of this to say that it actually is important that GlobalSign put messaging on their website and generally be proactive in limiting the chances for misinformation, confusion, and so forth to propagate across the Internet. 

The last thing I'll mention is that I have questions as to whether GlobalSign has violated either their own CPS or privacy policy when it comes to their subscribers‎. Admittedly I haven't had a chance to review either document so it's quite possible I'm misinformed and I hope someone will correct me as appropriate.

But the basic reasoning goes that there are some people who don't like Google and perhaps have chosen to use GlobalSign because they are not Google. Personally I think GlobalSign has an obligation to notify their subscribers with something to the effect that "after a certain date we will be sharing your payment information, certificate history, domain ownership, login activity to our Web portal, etc. with Google." However, if there are statements in either the doc that have been violated, that is a more serious issue.

The exact information being shared with (or is now available to) Google has not been publicly disclosed so I couldn't say for sure what should be communicated. Still, I imagine there are subscribers who would be surprised to learn that information they thought was constrained to just GlobalSign is no longer so. ‎I think it's only fair that subscribers (and relying parties) be offered a chance to opt-out even if it means subscribers leaving GlobalSign for some other vendor. I don't know that such an offering has been made?

‎I do hope that more can be publicly disclosed about what information is shared between GlobalSign and Google--including if the data sharing is related to only the 2 roots that were acquired or all GlobalSign roots.

From: Ryan Hurst via dev-security-policy Sent: Wednesday, March 8, 2017 11:29 AM‎

Gerv has already responded and while his response is correct I have a little more detail I can share, see bellow.

> Peter Kurrash: I'm trying to keep score here but am having difficulties. Can someone confirm if
> the following statements are correct:

> - Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself.

Correct, two root certificates and their keys were acquired.


> Peter Kurrash: GMO GlobalSign will continue to own other roots and will use only those other roots for
> the various products and services they choose to offer going forward. There is no affiliation or business
> relationship between GMO GlobalSign and Google after the completion of the acquisition.

Mostly correct, we do have a contractual obligation to GMO GlobalSign relative to the subordinate that exists under GlobalSign R2, that subordinate is owned and operated by GMO GlobalSign. The terms of this agreement require us to provide revocation services while they migrate their customers off. It also requires them to maintain their WebTrust accreditation.

I must also add that Google is large organization and may now, or in the future, have other agreements with GMO GlobalSign but I can say those agreements would likely be orthogonal to this transaction.


> Peter Kurrash:No public announcement of the acquisition was made prior to January 26, 2017
> via the Google security blog.

No, this is not correct, the first public announcement was at the CAB/Forum in mid October 2016 and the second was the Mozilla bug database on December 22nd, 2016.

> Peter Kurrash: No disclosure has been made regarding what specific items were acquired,
> including such things as: "private key material" (HSM's and whatnot); computer equipment used
> as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure
> used in the operations and maintenance of the acquired roots; data such as subscriber lists,
> databases, server logs, payment details and histories, certificate issuance activities and histories,
> etc.; any access rights to physical space such as offices, data centers, development and test
> facilities, and so forth; and last, but not least, any personnel, documentation, training materials,
> or other knowledge products. That is correct, we did not enumerate the items involved in the exchange.

The auditor's opinion letter covering the transfer is the most explicit public document covering the transfer.

I can say that the acquisition included the acquisition of the root key material and corresponding certificates. Additionally the transfer included tooling, documentation and training related to the aforementioned assets. The elements included were within the scope necessary to enable us to satisfy auditors of proper historical and future management of the associated keys.

For those who are interested I can also add we did not purchase the GMO GlobalSign HSMs, instead we purchased our own HSMs directly from the manufacturer. These HSMs were compatible with what were in use by GMO GlobalSign and we utilized the key migration capabilities of those devices to migrate those keys to our HSMs.

> Peter Kurrash: The scope of impact to existing GlobalSign customers is not known. Neither
> GMO GlobalSign nor Google have notified any existing clients of the acquisition.

I can not speak for GMO GlobalSign or what GMO GlobalSign has or has not told affected customers, that said I do know that they have updated their CP/CPS.

I can say that our key migration plan was chosen, in part, to provide GMO GlobalSign enough time to migrate affected customers to CAs operated under their other roots.

> Peter Kurrash: The GlobalSign web site has no mention of this acquisition for reasons which are
> unknown. Further, the web site does not make their CP/CPS documents readily available limiting the
> ability for current subscribers and relying parties to decide if continued use of a cert chaining up to > these roots is acceptable to them.

I can not speak for GMO GlobalSign or what GMO GlobalSign has or has not done, however a Google search of “GlobalSign CPS” has the first match of https://www.globalsign.com/en/repository/ which has their CP/CPS.

Additionally I am not aware of a requirement to do notification, I would only expect notification if it materially impacted them and I personally would argue that since GMO GlobalSign continues to operate many other roots as well as the related sub CA there is not a material impact.


> Peter Kurrash: A relying party who takes the initiative to review a certificate chain that goes up to either
> of the acquired roots will see that it is anchored (or "verified by") GlobalSign. No mention of Google will > be made anywhere in the user interface.

GMO GlobalSign continues to maintain an active WebTrust audit for the CA under R2. As the operator of the issuing CA, they are responsible for the verification of of the identity of the associated certificates. This includes those certificates they have historically issued as well as those they may issue in the future, given this, the above this statement is accurate.

Additionally it is also common for the name of the root not to match who is the current operator, for example in the 90s I created several roots for a company called ValiCert. Those roots have changed hands several times.

I can also say that the intent is for GMO GlobalSign to migrate existing customers off of this subordinate CA to one issued under one of their roots as soon as practical.


> Peter Kurrash: Google has acquired these roots in order to better serve their subscribers, which are
> organizations (not people) throughout the many Google companies. Relying parties (i.e. end users of
> the various Google products) are not affected positively or negatively by this acquisition.

Mostly true, though we have no product plans to disclose at this time we may, in the future issue certificates to people as well as to organizations outside of Google.


> Peter Kurrash: Mozilla granted Google's request to keep the acquisition confidential based on
> statements made by Google and Google's auditor E&Y. Neither GlobalSign nor their auditors offered
> any opinion on this matter.

Mostly true, both GMO GlobalSign and Google independently and together reached out to the respective root programs both before, during and after the transfer.

I can say the negotiation and execution of commercial contracts are commonly covered under nondisclosure agreements as are engagements with consultants and auditors. As such I would not expect in this, or in any other commercial negotiation for the parties involved to make public opinion statements about confidentiality.

[Peter Bowen]

On Thu, Mar 9, 2017 at 11:02 PM, Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> Of all these, Starfield seems to be the only case where a single CA
> name now refers to two different current CA operators (GoDaddy and
> Amazon). All the others are cases of complete takeover. None are
> cases where the name in the certificate is a still operating CA
> operator, but the root is actually operated by a different entity
> entirely.

There are a number of examples, but many of them are older and have
been removed from trust stores (usually due to key size):

Certplus - operated by both Docusign and Wosign
Starfield - Go Daddy and Amazon
TC TrustCenter - Symantec and Deutscher Sparkassen Verlag GmbH
(S-TRUST, DSV-Gruppe)
USERTRUST UTN-USERFirst - Symantec and Comodo
ValiCert - Go Daddy, SECOM, and RSA

Thanks,
Peter

[Gervase Markham]

On 07/03/17 10:18, Gervase Markham wrote:
> OK. Question for group: would it make sense to add the intermediate(s)
> that GlobalSign is using for this purpose directly to the Mozilla trust
> store, with the EV bit enabled, and then remove the EV bit from the
> roots now owned by Google Trust Services?
>
> This would scope EV permissions more closely to the audits, and so
> prevent Google from accidentally or intentionally issuing EV which was
> shown as such in Firefox, without having an EV audit.

Hearing no dissent, filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1347882

Gerv

[Gervase Markham]

On 08/03/17 16:20, Gervase Markham wrote:
> On 09/02/17 22:55, Peter Bowen wrote:
>> Policy Suggestion A) When transferring a root that is EV enabled, it
>> should be clearly stated whether the recipient of the root is also
>> receiving the EV policy OID(s).
>
> I agree with this suggestion; we should update
> https://wiki.mozilla.org/CA:RootTransferPolicy

Now done: "When transferring ownership of a root that is EV-enabled, it

should be clearly stated whether the recipient of the root is also

receiving the (right to use the) EV policy OID(s) and, if so, it should
be confirmed that they have or will get the relevant audits before
issuing EV certs."

> Again, would this be covered by a requirement that no issuance was
> permitted from a transferred root until all the paperwork was in place,
> including appropriately-scoped audits? This might lead to a PITRA, but
> would not have to.

Now done: "No issuance whatsoever is permitted from a root certificate
which has changed ownership by being sold by one company to another (as
opposed to by acquisition of the owning company) until the receiving
company has demonstrated to Mozilla that they have all the appropriate
audits, CP/CPS documents and other systems in place. In addition, if the
receiving company is new to the Mozilla root program, there must also be
a public discussion regarding their admittance to the root program."

https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership

Gerv

[Gervase Markham]

On 16/03/17 10:50, Gervase Markham wrote:
> https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership

With these changes and the filing of
https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this
particular discussion RESOLVED. This means Mozilla plans to take no
action against GTS based on what has been discovered and discussed. It
doesn't mean people can't continue to make suggestions about
improvements to our process, citing this situation.

Gerv

[Peter Kurrasch]

‎So this is the third of my 3 sets of criticisms regarding the acquisition of the GlobalSign roots by Google Trust Services. I apologize for the significant delay between the first 2 sets and this one. Hopefully people in the forum still feel this discussion relevant going forward even though the matter is considered resolved.

Several of the comments I made regarding GlobalSign also apply to Google, especially the intermingling of the two brands. The implications of the confusion and uncertainty leading to an exploitable attack are just as applicable to Google as they are to GlobalSign. However, when you consider the stature of Google both on the Internet and in consumer products, the ramifications are more significant. Or, if you will, the attack surface is quite different than if GlobalSign were to purchase a root from, say, Symantec.

I do fault Google for what I consider to be inadequate communication of the acquisition. This is not to say there's been no communication, just that I don't think it's enough, especially if you are not a CABF participant or don't keep up with Internet security news generally. Why not publish a message last October that regular folks on the Internet can understand? Why wait 3 months?‎ Why expect people to dig through a CPS to find what should be readily available information? 

I would be interested in knowing why Google felt it necessary to purchase an existing root instead of, for example, pursuing a "new root" path along the lines of what Let's Encrypt did? All I could gather from the Google security blog is that they really want to be a root CA and to do it in a hurry. ‎Why the need to do it quickly, especially given the risks (attack surface)?

I also would like to know what the plan or expectation is regarding formal separation between the infrastructures of Google and GlobalSign. The overlap is an understandable necessity during the transition but nonetheless presents another opportunity for improper access, loss (leaking) of data, and perhaps other nefarious activities. And, does Google have a published policy regarding the information collected, stored, and analyzed when people access the CRL and OCSP distribution nodes?

I do want to say I appreciate that someone with Ryan H.'s level of experience is involved in a transaction like this. There are undoubtedly many details to address that ensure a secure and proper transfer. I hope that someone on the GlobalSign side was equally experienced? The next time someone wants to purchase existing roots, the people involved might not have that same level of experience, and that should give everyone pause.


  Original Message  

From: Ryan Hurst via dev-security-policy

Sent: Wednesday, March 8, 2017 12:02 PM
To: mozilla-dev-s...@lists.mozilla.org
Reply To: Ryan Hurst

Subject: Re: Google Trust Services roots

[Ryan Sleevi]

On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> ‎I would be interested in knowing why Google felt it necessary to purchase

> an existing root instead of, for example, pursuing a "new root" path along
> the lines of what Let's Encrypt did? All I could gather from the Google
> security blog is that they really want to be a root CA and to do it in a
> hurry. ‎Why the need to do it quickly, especially given the risks (attack
> surface)?

Clarification: I'm not speaking on behalf of Google

I think this demonstrates a lack of understanding of what Let's Encrypt
did. Let's Encrypt obtained a cross-signed certificate (from IdenTrust),
which is "purchasing" a signature for their key. This is one approach.
Purchasing a pre-existing signature (and key) is another. They are
functionally equivalent.

So what Google has done is what is what Let's Encrypt did.

[Kurt Roeckx]

There are a few difference between the two:
- With the signature from IdenTrust, Let's encrypt is not a trusted root
CA, it's an intermediate CA. The ISRG also generated it's own root CA.
- Let's encrypt has it's own name (Let's encrypt, ISRG) on the
certificate. It's clear who the owner of the certificate it. It's not
clear that a GlobalSign certificate is not owned or controlled by
GlobalSign but instead by some other corporation that doesn't have any
relation to the first.


I find this second point rather annoying. As far as I know it's not the
first time something like that happened. I would not have a problem with
something like that if Google bought (all CAs from) GlobalSign, but I
dislike that some CAs which appear to be from the same company are
actually owned by several unrelated ones.


Kurt

[Roland Fantasia]

Anyone care to comment on the fact that Google's new subCAs under the GTS branding have inconsistent EKU and KU bits? What's more disturbing is FF doesn't make a fuss about it when connecting to the test sites (after adding the roots manually of course).

[Ryan Sleevi]

Clarified on the new thread you started, but I don't believe there's any
inconsistency. Further details on the new thread you started.

[okaphone.e...@gmail.com]

It's probably my ignorance in these matters, but how does purchasing a root certificate affect revocation?

Will that remain the responsibility of GlobalSign for any existing certificates that have been signed with these roots? (Those would be intermediate certificates, if I understand correctly.) Or does revocation also require signing, and does it therefore become the responsibility of the new owner of the roots?

[Gervase Markham]

On 27/03/17 23:18, okaphone.e...@gmail.com wrote:
> Will that remain the responsibility of GlobalSign for any existing
> certificates that have been signed with these roots? (Those would be
> intermediate certificates, if I understand correctly.) Or does
> revocation also require signing, and does it therefore become the
> responsibility of the new owner of the roots?

The latter - Mozilla would hold Google ultimately responsible for any
revocation-related requirements in these hierarchies. (They may, of
course, contract GlobalSign to manage some subset of it, but that's not
our business).

Gerv

[Peter Kurrasch]

(Renaming the thread to fork this particular discussion from any others on this transaction.)

You raise a fair point, Ryan‎: I'm not well versed in how Let's Encrypt went about establishing their roots. I thought I had a good understanding but perhaps I had missed something. When I went to the Let's Encrypt site I found a diagram that showed one of their intermediates as cross-signed by IdenTrust; no mention of a root acquisition. 

Again, perhaps I've missed something so please let me know if that's the case. In a ironic way, this very uncertainty demonstrates the kind of confusion I was trying to highlight with my is-it-Google-or-GlobalSign comments.

I think Kurt and I are on the same page regarding the precedent being established in this and prior acquisitions. In fact, I probably incorporated some of his points in my own commentary.‎ I'm not sure if he'll agree with the what I view as the danger here: By purchasing a single root certificate, Google (and anyone else) is redefining the very concept of "trust anchor".

Back in the early SSL days, one could look at the root cert, see the name on it, and decide right away if it's trustworthy ("oh yeah, I know VeriSign"). In other words, trust was contained entirely within the sequence of bytes that make up the root cert combined with one's own experience.

A significant change to that model happened when CA companies began to be purchased by other companies. However, since they were complete acquisitions, it isn't so hard‎ to add that one tidbit of knowledge to the thought process ("oh yeah, Symantec and VeriSign are the same"). So during this period of time trust was contained within the root certificate itself in conjunction with one's own experience and knowledge of CA company acquisitions.

As more roots entered the scene, it became more frequent for one to encounter a root CA company that was unfamiliar. However, one could decide to ignore it because it was in another jurisdiction (country, government institution, etc.) that was not pertinent. Or one could, in fairly short order, do some Internet research on the CA company and make a decision--including possibly reading their CP/CPS. So, in essence, the anchor of trust is contained within the root cert combined with one's own knowledge, experience, and some research.

Now, however, we are faced with a entirely different situation wherein the root certificate itself contributes little to establishing trust for a certificate chain. Any information contained in the cert is merely a starting point to research that particular cert: one must first determine who currently owns that root, possibly research the CA company if it's unfamiliar ("I know Google but what is this GTS all about?"), and probably ‎find and read the CP/CPS to find the details about the new ownership ("so who is handling revocation now?").

The kicker in all this is that one must perform these steps for every root one encounters, every time one encounters ‎it: Did GlobalSign sell any other roots since the last time I checked? Has Google transferred ownership of the GlobalSign roots they purchased on to someone else? What about this Amazon root or Comodo or...?

In other words, what used to be a trust anchor is now no better at establishing trust than the end-entity cert one is trying to validate or investigate (for example, in a forensic context) in the first place. I hardly think this redefinition of trust anchor improves the state of the global PKI and I sincerely hope it does not become a trend.

From: Kurt Roeckx via dev-security-policy Sent: Thursday, March 23, 2017 11:24 AM To: mozilla-dev-s...@lists.mozilla.org Reply To: Kurt Roeckx Subject: Re: Google Trust Services roots

On 2017-03-23 16:39, Ryan Sleevi wrote:

There are a few difference between the two:
- With the signature from IdenTrust, Let's encrypt is not a trusted root
CA, it's an intermediate CA. The ISRG also generated it's own root CA.
- Let's encrypt has it's own name (Let's encrypt, ISRG) on the
certificate. It's clear who the owner of the certificate it. It's not
clear that a GlobalSign certificate is not owned or controlled by
GlobalSign but instead by some other corporation that doesn't have any
relation to the first.


I find this second point rather annoying. As far as I know it's not the
first time something like that happened. I would not have a problem with
something like that if Google bought (all CAs from) GlobalSign, but I
dislike that some CAs which appear to be from the same company are
actually owned by several unrelated ones.


Kurt

[Gervase Markham]

On 29/03/17 15:35, Peter Kurrasch wrote:
> In other words, what used to be a trust anchor is now no better at
> establishing trust than the end-entity cert one is trying to validate or
> investigate (for example, in a forensic context) in the first place. I
> hardly think this redefinition of trust anchor improves the state of the
> global PKI and I sincerely hope it does not become a trend.

The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+ years.

Gerv

[Jakob Bohm]

That goal would be equally (in fact better) served by new market
entrants getting cross-signed by incumbents, like Let's encrypt did.

Problem is that whenever viewing a full cert chain in a typical browser
etc. that has reference "trusted" copies of all the incumbents,
disassociating the names in root CA and SubCA certificates from reality
creates misinformation in a context displayed as being "fully
validated" to known traceable roots by the Browser/etc.

For example, when doing ordinary browsing with https on-by-default,
users rarely bother checking the certificate beyond "the browser says
it is not a MitM attack, good". Except when visiting a high value
site, such as a government site to file a change in ownership of an
entire house (such sites DO exist). Then it makes sense to click on
the certificate user interface and check that the supposed "Government
Land Ownership Registry of the Kingdom of X" site is verified by
someone that could reasonably be trusted to do so (i.e. not a national
CA of the republic of Y or the semi-internal CA of some private
megacorp).

With this recent transaction, the browser could show "GlobalSign" when
it should show "Google", two companies with very different security and
privacy reputations. One would expect a blogger/blogblog domain to
have a Google-issued certificate while one would expect the opposite of
anything hosted outside the Alphabet group.

[Peter Kurrasch]

I'm not so sure I want to optimize the system in that way, but I am concerned about the (un)intended consequences of rapidly changing root ownership on the global PKI.

It's not inconsequential for Google to say: "From now on, nobody can trust what you see in the root certificate, even if some of it appears in the browser UI. The only way you can actually establish trust is to do frequent, possibly complicated research." It doesn't seem right that Google be allowed to unilaterally impose that change on the global PKI without any discussion from the security community.

But you bring up a good point that there seems to be much interest of late to speed up the cycle times for various activities within the global PKI but it's not entirely clear to me what's driving it. My impression is that Google was keen to become a CA in their own right as quickly as possible, so is this interest based on what Google wants? Or is there a Mozilla mandate that I haven't seen (or someone else's mandate?)?


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Wednesday, March 29, 2017 9:48 AM
To: mozilla-dev-s...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 29/03/17 15:35, Peter Kurrasch wrote:

> In other words, what used to be a trust anchor is now no better at
> establishing trust than the end-entity cert one is trying to validate or
> investigate (for example, in a forensic context) in the first place. I
> hardly think this redefinition of trust anchor improves the state of the
> global PKI and I sincerely hope it does not become a trend.

The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+ years.

Gerv

[Alex Gaynor]

I don't think it's a good idea to design our system around the idea of
"What would a user be looking for if they read the cert chain manually".
For example, in the US, if such a government agency chose to use a
Government CA (as a user might reasonably expect!), their users would all
get cert warnings with the Mozilla trust DB!

Even as someone pretty well versed in the WebPKI, I don't think my
expectations about who the CA for a given site should be really are
actionable.

It seems to be that certs are for computers to consume, and only
incidentally for humans to read (*hit tip* to SICP).

Alex

PS: To expand a bit on this thought experiment, if I were to enumerate all
CAs over a bunch of websites, the only cases I can think of where human
intuition has a defensible conclusion, is that certain CAs _shouldn't_ sign
things, notably CAs intended only for limited usage (e.g. a Government CA
designed for signing government website certs). These cases are, I think,
much better handled by Name Constraints (or some other technical
constraint), and that's an entirely different subject altogether.

On Wed, Mar 29, 2017 at 2:42 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 29/03/2017 16:47, Gervase Markham wrote:
>

[Jakob Bohm]

On 29/03/2017 20:52, Alex Gaynor wrote:
> I don't think it's a good idea to design our system around the idea of
> "What would a user be looking for if they read the cert chain manually".
> For example, in the US, if such a government agency chose to use a
> Government CA (as a user might reasonably expect!), their users would all
> get cert warnings with the Mozilla trust DB!
>
> Even as someone pretty well versed in the WebPKI, I don't think my
> expectations about who the CA for a given site should be really are
> actionable.
>
> It seems to be that certs are for computers to consume, and only
> incidentally for humans to read (*hit tip* to SICP).
>
> Alex
>
> PS: To expand a bit on this thought experiment, if I were to enumerate all
> CAs over a bunch of websites, the only cases I can think of where human
> intuition has a defensible conclusion, is that certain CAs _shouldn't_ sign
> things, notably CAs intended only for limited usage (e.g. a Government CA
> designed for signing government website certs). These cases are, I think,
> much better handled by Name Constraints (or some other technical
> constraint), and that's an entirely different subject altogether.
>

Which was precisely my point, except that to date, the few implemented
forms of name constraints seem unable to capture the real world
considerations that should exclude most CAs from a considerable part of
the Web name space:

- Country-specific CAs want to sign certificates for GTLD sites (.com,
.net, .org, .name etc.) that are actually under that country
jurisdiction.
- Cloud-hosting provider CAs (Microsoft, Google, Amazon) want to sign
certificates for anything they host, regardless of TLD or country.

- Neither are appropriate CAs for any sites not under their
administration/jurisdiction.

The special case of the old US Gov CA getting thrown out of Mozilla and
some other browsers is something of an outlier, but even then, it would
be odd if a US Gov site had a certificate from the Taiwan GRCA or the
Spanish guild of public notaries.

So until relevant technical constraints are actually ubiquitous in the
WebPKI, manual checking remains relevant.

[Gervase Markham]

On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it
> appears in the browser UI. The only way you can actually establish
> trust is to do frequent, possibly complicated research." It doesn't
> seem right that Google be allowed to unilaterally impose that change
> on the global PKI without any discussion from the security
> community.

As others in this thread have pointed out, this is not a new thing. I
wouldn't say that Google is "imposing" this need.

Gerv

[Gervase Markham]

On 29/03/17 20:42, Jakob Bohm wrote:
> That goal would be equally (in fact better) served by new market
> entrants getting cross-signed by incumbents, like Let's encrypt did.

Google will be issuing from Google-branded intermediates under the
ex-GlobalSign roots. So the chains would be basically the same whether
GS or GTS owned the parent root. So how does requiring them to do it by
cross-signing improve things? Requiring them to do it by cross-signing
just exposes them to business risk which they don't have if they
actually own the roots.

> For example, when doing ordinary browsing with https on-by-default,
> users rarely bother checking the certificate beyond "the browser says
> it is not a MitM attack, good". Except when visiting a high value
> site, such as a government site to file a change in ownership of an
> entire house (such sites DO exist). Then it makes sense to click on
> the certificate user interface and check that the supposed "Government
> Land Ownership Registry of the Kingdom of X" site is verified by
> someone that could reasonably be trusted to do so (i.e. not a national
> CA of the republic of Y or the semi-internal CA of some private
> megacorp).

This is what we have CAA and HPKP for.

> With this recent transaction, the browser could show "GlobalSign" when
> it should show "Google", two companies with very different security and
> privacy reputations.

If Google were issuing from a Google-owned intermediate under a
GlobalSign-owned root, why would the browser show "Google"? I don't
understand how you see the chain differing in this situation.

Gerv

[Peter Kurrasch]

By "not new", are you referring to Google being the second(?) instance where a company has purchased an individual root cert from another company? It's fair enough to say that Google isn't the first but I'm not aware of any commentary or airing of opposing viewpoints as to the suitability of this practice going forward.

Has Mozilla received any notification that other companies ‎intend to acquire individual roots from another CA? I wouldn't ask Mozilla to violate any non-disclosures but surely it's possible to let the community know if we should expect more of this? Ryan H. implied as much in a previous post but I wasn't sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root acquisition? For example, how frequently should roots be allowed to change hands? What would Mozilla's response be if WoSign were to say that because of the tarnishing of their own brand they are acquiring the HARICA root? What if Vladimir Putin were to make such a purchase? Any requirements on companies notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector of the global PKI but I'm not sure who else is in a better position for that role?

  Original Message  
From: Gervase Markham via dev-security-policy

Sent: Thursday, March 30, 2017 1:06 AM

To: mozilla-dev-s...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 29/03/17 20:46, Peter Kurrasch wrote:

> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it
> appears in the browser UI. The only way you can actually establish
> trust is to do frequent, possibly complicated research." It doesn't
> seem right that Google be allowed to unilaterally impose that change
> on the global PKI without any discussion from the security
> community.

As others in this thread have pointed out, this is not a new thing. I
wouldn't say that Google is "imposing" this need.

[Richard Wang]

To be transparent, WoSign are NOT "acquiring the HARICA root" that we NEVER contact HARICA, and we don't think our brand is "tarnishing", we are working hard to try to regain the trust and confidence in this community.

Best Regards,

Richard

-----Original Message-----

From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Peter Kurrasch via dev-security-policy
Sent: Thursday, March 30, 2017 9:02 PM
To: Gervase Markham via dev-security-policy <ge...@mozilla.org>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

By "not new", are you referring to Google being the second(?) instance where a company has purchased an individual root cert from another company? It's fair enough to say that Google isn't the first but I'm not aware of any commentary or airing of opposing viewpoints as to the suitability of this practice going forward.

Has Mozilla received any notification that other companies ‎intend to acquire individual roots from another CA? I wouldn't ask Mozilla to violate any non-disclosures but surely it's possible to let the community know if we should expect more of this? Ryan H. implied as much in a previous post but I wasn't sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root acquisition? For example, how frequently should roots be allowed to change hands? What would Mozilla's response be if WoSign were to say that because of the tarnishing of their own brand they are acquiring the HARICA root? What if Vladimir Putin were to make such a purchase? Any requirements on companies notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector of the global PKI but I'm not sure who else is in a better position for that role?

Original Message
From: Gervase Markham via dev-security-policy

Sent: Thursday, March 30, 2017 1:06 AM

To: mozilla-dev-s...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 29/03/17 20:46, Peter Kurrasch wrote:

> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it appears
> in the browser UI. The only way you can actually establish trust is to
> do frequent, possibly complicated research." It doesn't seem right
> that Google be allowed to unilaterally impose that change on the
> global PKI without any discussion from the security community.

As others in this thread have pointed out, this is not a new thing. I wouldn't say that Google is "imposing" this need.

[uri...@gmail.com]

> and we don't think our brand is "tarnishing", we are working hard to try to regain the trust and confidence in this community.

Wasn't a prerequisite for that process your stepping down as CEO of WoSign?

[Florian Weimer]

* Peter Kurrasch via dev-security-policy:

> By "not new", are you referring to Google being the second(?) instance
> where a company has purchased an individual root cert from another
> company? It's fair enough to say that Google isn't the first but I'm
> not aware of any commentary or airing of opposing viewpoints as to the
> suitability of this practice going forward.

I think most of the DNs in the Mozilla root store still do not reflect
reality. The restrictions on certificate naming do not apply to the
CAs themselves. This is due to the way PKIX validation works.
Correcting the DNs would break the certificate chains.

[Richard Wang]

Qihoo 360 CSO Mr. Tan updated this in the recent CAB Forum meeting in USA : CEO of WoSign is NA, Richard Wang is the COO.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of urijah--- via dev-security-policy
Sent: Friday, March 31, 2017 2:07 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots

> and we don't think our brand is "tarnishing", we are working hard to try to regain the trust and confidence in this community.

Wasn't a prerequisite for that process your stepping down as CEO of WoSign?



On Thursday, March 30, 2017 at 9:49:25 PM UTC-4, Richard Wang wrote:

[Dimitris Zacharopoulos]

On 30/3/2017 4:01 μμ, Peter Kurrasch via dev-security-policy wrote:
> By "not new", are you referring to Google being the second(?) instance where a company has purchased an individual root cert from another company? It's fair enough to say that Google isn't the first but I'm not aware of any commentary or airing of opposing viewpoints as to the suitability of this practice going forward.
>
> Has Mozilla received any notification that other companies ‎intend to acquire individual roots from another CA? I wouldn't ask Mozilla to violate any non-disclosures but surely it's possible to let the community know if we should expect more of this? Ryan H. implied as much in a previous post but I wasn't sure where he was coming from on that.
>
> Also, does Mozilla have any policies (requirements?) regarding individual root acquisition? For example, how frequently should roots be allowed to change hands? What would Mozilla's response be if WoSign were to say that because of the tarnishing of their own brand they are acquiring the HARICA root? What if Vladimir Putin were to make such a purchase? Any requirements on companies notifying the public when the acquisition takes place?
>
> Perhaps this is putting too much of a burden on Mozilla as a somewhat protector of the global PKI but I'm not sure who else is in a better position for that role?

Hi Peter,

This public discussion around the Root transfer, triggered an update in
Mozilla's Root Transfer Policy
<https://wiki.mozilla.org/CA:RootTransferPolicy>. Specifically (emphasis
mine):

"No issuance whatsoever is permitted from a root certificate which has
changed ownership by being sold by one company to another (as opposed to
by acquisition of the owning company) until the receiving company has
demonstrated to Mozilla that they have all the appropriate audits,

CP/CPS documents and other systems in place. In addition, *if the

receiving company is new to the Mozilla root program, there must also be

a public discussion regarding their admittance to the root program. *"

I believe this covers the "unknown" members to the Mozilla Root program
quite well. I would also suggest that you try not to use existing
Companies/Organizations as examples (although I also find it very
tempting sometimes) because there may be misunderstandings :)


Dimitris.

>
> Original Message
> From: Gervase Markham via dev-security-policy

> Sent: Thursday, March 30, 2017 1:06 AM

> To: mozilla-dev-s...@lists.mozilla.org
> Reply To: Gervase Markham
> Subject: Re: Criticism of Google Re: Google Trust Services roots
>

> On 29/03/17 20:46, Peter Kurrasch wrote:

>> It's not inconsequential for Google to say: "From now on, nobody can
>> trust what you see in the root certificate, even if some of it
>> appears in the browser UI. The only way you can actually establish
>> trust is to do frequent, possibly complicated research." It doesn't
>> seem right that Google be allowed to unilaterally impose that change
>> on the global PKI without any discussion from the security
>> community.

> As others in this thread have pointed out, this is not a new thing. I
> wouldn't say that Google is "imposing" this need.
>

[Jakob Bohm]

On 30/03/2017 08:08, Gervase Markham wrote:
> On 29/03/17 20:42, Jakob Bohm wrote:
>> That goal would be equally (in fact better) served by new market
>> entrants getting cross-signed by incumbents, like Let's encrypt did.
>
> Google will be issuing from Google-branded intermediates under the
> ex-GlobalSign roots. So the chains would be basically the same whether
> GS or GTS owned the parent root. So how does requiring them to do it by
> cross-signing improve things? Requiring them to do it by cross-signing
> just exposes them to business risk which they don't have if they
> actually own the roots.
>
>> For example, when doing ordinary browsing with https on-by-default,
>> users rarely bother checking the certificate beyond "the browser says
>> it is not a MitM attack, good". Except when visiting a high value
>> site, such as a government site to file a change in ownership of an
>> entire house (such sites DO exist). Then it makes sense to click on
>> the certificate user interface and check that the supposed "Government
>> Land Ownership Registry of the Kingdom of X" site is verified by
>> someone that could reasonably be trusted to do so (i.e. not a national
>> CA of the republic of Y or the semi-internal CA of some private
>> megacorp).
>
> This is what we have CAA and HPKP for.

Those only work for sites that are able to deploy those (there are
technical limitations blocking deployment on some systems).

They by no means replace due diligence in high risk situations.

>
>> With this recent transaction, the browser could show "GlobalSign" when
>> it should show "Google", two companies with very different security and
>> privacy reputations.
>
> If Google were issuing from a Google-owned intermediate under a
> GlobalSign-owned root, why would the browser show "Google"? I don't
> understand how you see the chain differing in this situation.
>

I am (consistently) referring to situations where the user has reason
to navigate to the part of the UI that displays the full chain, not the
dubious tooltips displayed under the encryption icon.

[Gervase Markham]

On 30/03/17 15:01, Peter Kurrasch wrote:
> By "not new", are you referring to Google being the second(?)
> instance where a company has purchased an individual root cert from
> another company? It's fair enough to say that Google isn't the first
> but I'm not aware of any commentary or airing of opposing viewpoints
> as to the suitability of this practice going forward.

As noted, I have no interest in banning this practice because I think
the ecosystem effects would be negative.

> Has Mozilla received any notification that other companies ‎intend to
> acquire individual roots from another CA?

Not to my knowledge, but they may have been communicating with Kathleen.

> Also, does Mozilla have any policies (requirements?) regarding
> individual root acquisition?

https://wiki.mozilla.org/CA:RootTransferPolicy
and
https://github.com/mozilla/pkipolicy/issues/57

> For example, how frequently should roots
> be allowed to change hands? What would Mozilla's response be if
> WoSign were to say that because of the tarnishing of their own brand
> they are acquiring the HARICA root?

>From the above URL: "In addition, if the receiving company is new to the

Mozilla root program, there must also be a public discussion regarding
their admittance to the root program."

Without completing the necessary steps, WoSign would not be admitted to
the root program.

Gerv

[Peter Bowen]

On Fri, Mar 31, 2017 at 8:18 AM, Gervase Markham via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> On 30/03/17 15:01, Peter Kurrasch wrote:

>> By "not new", are you referring to Google being the second(?)
>> instance where a company has purchased an individual root cert from
>> another company? It's fair enough to say that Google isn't the first
>> but I'm not aware of any commentary or airing of opposing viewpoints
>> as to the suitability of this practice going forward.
>

> As noted, I have no interest in banning this practice because I think
> the ecosystem effects would be negative.
>

>> Has Mozilla received any notification that other companies ‎intend to
>> acquire individual roots from another CA?
>

> Not to my knowledge, but they may have been communicating with Kathleen.
>

>> Also, does Mozilla have any policies (requirements?) regarding
>> individual root acquisition?
>

> https://wiki.mozilla.org/CA:RootTransferPolicy
> and
> https://github.com/mozilla/pkipolicy/issues/57
>

>> For example, how frequently should roots
>> be allowed to change hands? What would Mozilla's response be if

>> GalaxyTrust (an operator not in the program)
>> were to say that they are acquiring the HARICA root?

>
> From the above URL: "In addition, if the receiving company is new to the
> Mozilla root program, there must also be a public discussion regarding
> their admittance to the root program."
>

> Without completing the necessary steps, GalaxyTrust would not be admitted to
> the root program.

I've modified the quoted text a little to try to make this example
clearer, as I think the prior example conflated multiple things and
used language that did not help clarify the situation.

Is the revised example accurate?

Thanks,
Peter

[Gervase Markham]

On 31/03/17 17:39, Peter Bowen wrote:
>>> For example, how frequently should roots
>>> be allowed to change hands? What would Mozilla's response be if
>>> GalaxyTrust (an operator not in the program)
>>> were to say that they are acquiring the HARICA root?
>>
>> From the above URL: "In addition, if the receiving company is new to the
>> Mozilla root program, there must also be a public discussion regarding
>> their admittance to the root program."
>>
>> Without completing the necessary steps, GalaxyTrust would not be admitted to
>> the root program.
>
> I've modified the quoted text a little to try to make this example
> clearer, as I think the prior example conflated multiple things and
> used language that did not help clarify the situation.
>
> Is the revised example accurate?

The revised example is accurate.

Gerv

[Peter Kurrasch]

The revised example is not entirely what I had in mind (more on that in a minute) but as written now is mostly OK by me. I do have a question as to whether the public discussion as mentioned must take place before the actual transfer? In other words, will Mozilla require that whatever entity is trying to purchase the root must be fully admitted into the root program before the transfer takes place?

Also, let me state that I did not intend to besmirch the names of either HARICA or WoSign and I appreciate their indulging my use of their names in what turned out to be a sloppy illustration. Based on my review of HARICA's CPS some months ago, I was left with the impression of them as a tightly-focused ‎organization that, by all appearances, is well-run. And that was the image I had mind and had hoped to convey in using their name. By mentioning WoSign I was really thinking of only the state of their reputation at the moment--and I think it's fair to say it's been tarnished? The reasons for WoSign being in the position they are in were totally irrelevant to what I had in mind.

So what was my point? In essence, I wanted to suggest that not every company seeking to purchase a root from another company will necessarily have good intentions and even if they do, their intentions might not be in the interest of the public good. I think it's important to at least acknowledge that possibility and try to have policies in place that encourage the good and limit the bad.

I don't know if people are on board with this notion or if some hypothetical scenarios are needed at this point? For now I'll just pause and let others either ask or comment away.

  Original Message  
From: Gervase Markham via dev-security-policy

Sent: Friday, March 31, 2017 12:28 PM

To: mozilla-dev-s...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots

On 31/03/17 17:39, Peter Bowen wrote:

>>> For example, how frequently should roots
>>> be allowed to change hands? What would Mozilla's response be if
>>> GalaxyTrust (an operator not in the program)
>>> were to say that they are acquiring the HARICA root?
>>
>> From the above URL: "In addition, if the receiving company is new to the
>> Mozilla root program, there must also be a public discussion regarding
>> their admittance to the root program."
>>
>> Without completing the necessary steps, GalaxyTrust would not be admitted to
>> the root program.
>
> I've modified the quoted text a little to try to make this example
> clearer, as I think the prior example conflated multiple things and
> used language that did not help clarify the situation.
>
> Is the revised example accurate?

The revised example is accurate.

[Gervase Markham]

On 31/03/17 20:26, Peter Kurrasch wrote:
> The revised example is not entirely what I had in mind (more on that
> in a minute) but as written now is mostly OK by me. I do have a
> question as to whether the public discussion as mentioned must take
> place before the actual transfer? In other words, will Mozilla
> require that whatever entity is trying to purchase the root must be
> fully admitted into the root program before the transfer takes
> place?

No. As currently worded, it has to take place before issuance is permitted.

Gerv

[Peter Kurrasch]

I must be missing something still? The implication here is that a purchaser who is not yet part of the root program is permitted to take possession of the root cert private key and possibly the physical space, key personnel, networking infrastructure, revocation systems, and responsibility for subordinates without having first demonstrated any competence at ‎running a CA organization.

I think we need to beef up this section of the policy but if you'd prefer to discuss that at a later time (separate from the Google acquisition thread), that will work for me.

  Original Message  
From: Gervase Markham

Sent: Saturday, April 1, 2017 6:02 AM
To: Peter Kurrasch; mozilla-dev-s...@lists.mozilla.org

Subject: Re: Criticism of Google Re: Google Trust Services roots

On 31/03/17 20:26, Peter Kurrasch wrote:

> The revised example is not entirely what I had in mind (more on that
> in a minute) but as written now is mostly OK by me. I do have a
> question as to whether the public discussion as mentioned must take
> place before the actual transfer? In other words, will Mozilla
> require that whatever entity is trying to purchase the root must be
> fully admitted into the root program before the transfer takes
> place?

[Nick Lamb]

On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote:
> I must be missing something still? The implication here is that a purchaser who is not yet part of the root program is permitted to take possession of the root cert private key and possibly the physical space, key personnel, networking infrastructure, revocation systems, and responsibility for subordinates without having first demonstrated any competence at ‎running a CA organization.

This appears to me to simply be a fact, not a policy.

Suppose Honest Achmed's used car business has got him into serious debt. Facing bankruptcy, Achmed is ordered by a court to immediately sell the CA to another company Rich & Dick LLC, which has never historically operated a CA but has made informal offers previously.

Now, Mozilla could say, OK, if that happens we'll immediately distrust the root. But to what end? This massively inconveniences everybody, there's no upside except that in the hypothetical scenario where Rick & Dick are bad guys the end users are protected (eventually, as distrust trickles out into the wild) from bad issuances they might make. But a single such issuance would trigger that distrust already under the policy as written and we have no reason to suppose they're bad guys.

On the other hand, if Rich & Dick are actually an honest outfit, the policy as written lets them talk to Mozilla, make representations to m.d.s.policy and get themselves trusted, leaving the existing Honest Achmed subscribers with working certificates while everything is straightened out, all Rich & Dick need to do is leave issuance switched off while they reach an agreement.

Because continuing trust is always at Mozilla's discretion if something truly egregious happened (e.g. Achmed's CA is declared bankrupt, a San Francisco start-up with four employees and $6Bn of capital buys their hardware for pennies on the dollar and announces it'll be issuing free MITM SSL certificates starting Monday morning) then Mozilla is still free to take extraordinary action and distrust Achmed's root immediately without waiting until Monday morning.

[Peter Kurrasch]

I have no issue with the situations you describe below. Mozilla should act to encourage the good behaviors that we would want a new, acquiring CA to exhibit while prohibiting the bad--or at least limiting the damage those bad behaviors might cause. It's in this latter category that I think the current policy falls short.

Consider a situation in which I have a business called Easy Pete's Finishing School for Nigerian Princes. As the name might suggest, the nature of my business is to train potential scammer after potential scammer and set them free on the Internet to conduct whatever naughty things they like. It's a very lucrative business so when I see a root cert coming up for sale it's a no-brainer for me to go out and purchase it. Having access to a root will undoubtedly come in handy as I grow my business.

Once I take possession of the root cert's private key and related assets, what will limit the bad actions that I intend to take? For the sake of appearances (to look like a good-guy CA) I'll apply to join the Mozilla root program but I'm only really going through the motions--even in a year's time I don't really expect to be any closer to completing the necessary steps to become an actual member.

And it's true that I may be prohibited from issuing certs per Mozilla policy, but that actually is a bit of a squishy statement. For example, I'll still need to reissue certs to the existing customers ‎as their certs expire or if they need rekeying. Perhaps I'll also get those clients to provide me with their private key so I may hold it for "safe keeping". Sure, it's a violation of the BR's but I'm not concerned with that. Besides, it will take some time until anyone even figures out what I'm doing.

The other recourse in the current policy is to distrust the root cert altogether. Even then it will take time to take full effect and who knows, maybe I can still use the root for code signing? And then there are the existing customers who are left holding a soon-to-be worthless cert....

Leaving behind this land of hypotheticals‎, it seems to me the policy as written is weaker than it ought to be. My own opinion is that only a member CA should be allowed to purchase a root cert (and assets), regardless if it's only one cert or the whole company. If that's going too far, I think details are needed for what "regular business operations" are allowed during the period between acquisition of the root and acceptance into the Mozilla root program. And should there be a maximum time allowed to become such a member?

From: Nick Lamb via dev-security-policy Sent: Tuesday, April 4, 2017 3:42 AM To: mozilla-dev-s...@lists.mozilla.org

Reply To: Nick Lamb Subject: Re: Criticism of Google Re: Google Trust Services roots

On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote:

> I must be missing something still? The implication here is that a purchaser who is not yet part of the root program is permitted to take possession of the root cert private key and possibly the physical space, key personnel, networking infrastructure, revocation systems, and responsibility for subordinates without having first demonstrated any competence at ‎running a CA organization.

This appears to me to simply be a fact, not a policy.

Suppose Honest Achmed's used car business has got him into serious debt. Facing bankruptcy, Achmed is ordered by a court to immediately sell the CA to another company Rich & Dick LLC, which has never historically operated a CA but has made informal offers previously.

Now, Mozilla could say, OK, if that happens we'll immediately distrust the root. But to what end? This massively inconveniences everybody, there's no upside except that in the hypothetical scenario where Rick & Dick are bad guys the end users are protected (eventually, as distrust trickles out into the wild) from bad issuances they might make. But a single such issuance would trigger that distrust already under the policy as written and we have no reason to suppose they're bad guys.

On the other hand, if Rich & Dick are actually an honest outfit, the policy as written lets them talk to Mozilla, make representations to m.d.s.policy and get themselves trusted, leaving the existing Honest Achmed subscribers with working certificates while everything is straightened out, all Rich & Dick need to do is leave issuance switched off while they reach an agreement.

Because continuing trust is always at Mozilla's discretion if something truly egregious happened (e.g. Achmed's CA is declared bankrupt, a San Francisco start-up with four employees and $6Bn of capital buys their hardware for pennies on the dollar and announces it'll be issuing free MITM SSL certificates starting Monday morning) then Mozilla is still free to take extraordinary action and distrust Achmed's root immediately without waiting until Monday morning.

[j...@0.me.uk]

On Thursday, April 6, 2017 at 3:24:53 AM UTC+1, Peter Kurrasch wrote:
> I have no issue with the situations you describe below. Mozilla should act to encourage the good behaviors that we would want a new, acquiring CA to exhibit while prohibiting the bad--or at least limiting the damage those bad behaviors might cause. It's in this latter category that I think the current policy falls short.
>
>
> Consider a situation in which I have a business called Easy Pete's Finishing School for Nigerian Princes. As the name might suggest, the nature of my business is to train potential scammer after potential scammer and set them free on the Internet to conduct whatever naughty things they like. It's a very lucrative business so when I see a root cert coming up for sale it's a no-brainer for me to go out and purchase it. Having access to a root will undoubtedly come in handy as I grow my business.
>
>
> Once I take possession of the root cert's private key and related assets, what will limit the bad actions that I intend to take? For the sake of appearances (to look like a good-guy CA) I'll apply to join the Mozilla root program but I'm only really going through the motions--even in a year's time I don't really expect to be any closer to completing the necessary steps to become an actual member.
>
>
> And it's true that I may be prohibited from issuing certs per Mozilla policy, but that actually is a bit of a squishy statement. For example, I'll still need to reissue certs to the existing customers ‎as their certs expire or if they need rekeying. Perhaps I'll also get those clients to provide me with their private key so I may hold it for "safe keeping". Sure, it's a violation of the BR's but I'm not concerned with that. Besides, it will take some time until anyone even figures out what I'm doing.
>
>
> The other recourse in the current policy is to distrust the root cert altogether. Even then it will take time to take full effect and who knows, maybe I can still use the root for code signing? And then there are the existing customers who are left holding a soon-to-be worthless cert....
>
>
>
>
> Leaving behind this land of hypotheticals‎, it seems to me the policy as written is weaker than it ought to be. My own opinion is that only a member CA should be allowed to purchase a root cert (and assets), regardless if it's only one cert or the whole company. If that's going too far, I think details are needed for what "regular business operations" are allowed during the period between acquisition of the root and acceptance into the Mozilla root program. And should there be a maximum time allowed to become such a member?

Mozilla could change it policy to say that any newly acquired roots which are not bought by existing root members should have temporary distrust block placed on the root until new program member has met all the requirements defined in the root program inclusion policy and if the root member doesn't meet the requirements within x amount of time the root will be remove permanently from the root store.

I understand this option would affect the existing subscribers using that particular root but we must maintain certain level of trust in the root program.

[Jakob Bohm]

Here are some ideas for reasonable new/enhanced policies (rough
sketches to be discussed and honed before insertion into a future
Mozilla policy version):

1. If a CA operator (the entity whose audits and statements ensures
compliance with BR, CCADB, Mozilla, etc. policy requirements) ceases
operation without transferring the relevant assets and
responsibilities, it must notify the CCADB and/or Mozilla and
indicate which, if any, provisions are in place for ensuring orderly
handling of issued certificate revocations etc. during a transition
period. Based on this Mozilla will decide when to remove the
affected roots from its trust store, and if any protective filters
will be added to ensure the wind down operator does not issue new
certificates contrary to the wind down plan. All CA operators are
encouraged to have a pre-assessed contingency plan for this already
on file within or along with its CP/CPS documents, such that Mozilla
may express, before such an event, what the consequences for
certificate holders and relying parties would be should the plan ever
get invoked.

2. If a CA operator wishes to transfer operations control of a CA
private key to a different CA operator not already accepted into the
Mozilla root program for the applicable trust aspects (web, web EV,
mail etc.), it must if at all possible delay the actual transfer of
control or possession until Mozilla has received and processed such
an application. The gaining applicant may indicate in their
application that the application is for the potential takeover of one
or more existing roots (named or not at that stage). It is
explicitly noted that the contractual and economic aspects of such a
transfer may happen before the actual transfer, making it easier to
comply with financial and other regulations regarding disclosure of
such a transaction.

3. If a CA operator organization has a significant change in its
controlling ownership, it must notify Mozilla and/or the CCADB as
soon as possible, with a confidential notification possibly preceding
the public notification. Mozilla shall be entitled to reassess its
trust in the CAs operated by that CA operator based on the public
reputation and public assurances made by the new owners. It is
explicitly noted that de facto authority over existing CA operator
personnel, rather than de jure completion of a sale/merger/etc. is
the relevant point in time, thus if possible, Mozilla should be
notified (in confidence if need be) before that point.

4. If a CA operator organization changes only its formal legal
structure while leaving the controlling ownership and other essential
aspects intact, Mozilla considers this a minor event for which a
simple update in the CCADB is sufficient. This generally does not
change the trust status of the CAs operated by that CA operator.

> *From: *Nick Lamb via dev-security-policy
> *Sent: *Tuesday, April 4, 2017 3:42 AM
> *To: *mozilla-dev-s...@lists.mozilla.org
> *Reply To: *Nick Lamb
> *Subject: *Re: Criticism of Google Re: Google Trust Services roots

[Ryan Sleevi]

On Thu, Apr 6, 2017 at 1:42 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> Here are some ideas for reasonable new/enhanced policies (rough
> sketches to be discussed and honed before insertion into a future
> Mozilla policy version):
>

Are you suggesting that the current policies that have been pointed out are
insufficient to address these cases?

[Jakob Bohm]

Others have suggested they were insufficient, I just tried to come up
with a wording for what others said was lacking.

[Gervase Markham]

On 06/04/17 03:24, Peter Kurrasch wrote:
> things they like. It's a very lucrative business so when I see a root
> cert coming up for sale it's a no-brainer for me to go out and purchase
> it. Having access to a root will undoubtedly come in handy as I grow my
> business.

The previous owner of the root cert, certainly if they have other roots
and even if they don't, has an obligation to notify us of the sale.
Until they do, they remain responsible for it, and whatever Easy Pete
does with it.

So I expect us to find out about the sale.

> Once I take possession of the root cert's private key and related
> assets, what will limit the bad actions that I intend to take?

If you start issuing certs without the relevant paperwork in place,
you'll be out of the root programs in the next security update, and
you'll have spent a lot of money on a worthless asset.

> And it's true that I may be prohibited from issuing certs per Mozilla
> policy, but that actually is a bit of a squishy statement. For example,
> I'll still need to reissue certs to the existing customers ‎as their
> certs expire or if they need rekeying.

Er, no. No issuance is permitted. If you need to issue immediately, then
you need to make sure the paperwork is in place and Mozilla is happy
before possession is transferred. Then you can have near-uninterrupted
service.

> Leaving behind this land of hypotheticals‎, it seems to me the policy as
> written is weaker than it ought to be. My own opinion is that only a
> member CA should be allowed to purchase a root cert (and assets),
> regardless if it's only one cert or the whole company.

As noted in previous emails, I see membership as a consequence of owning
an included root, rather than a separate thing. Clearly there are grey
areas on joining and leaving, but it doesn't make sense to me for a
company to be a member of the program if they don't own a root.

> If that's going
> too far, I think details are needed for what "regular business
> operations" are allowed during the period between acquisition of the
> root and acceptance into the Mozilla root program.

None. The root transfer policy is very clear:

"No issuance whatsoever is permitted from a root certificate which has
changed ownership by being sold by one company to another (as opposed to
by acquisition of the owning company) until the receiving company has
demonstrated to Mozilla that they have all the appropriate audits,

CP/CPS documents and other systems in place. In addition, if the

receiving company is new to the Mozilla root program, there must also be
a public discussion regarding their admittance to the root program."

https://wiki.mozilla.org/CA:RootTransferPolicy

A wise company would do this all in advance of taking possession if they
wanted to issue immediately upon acquisition.

In the GS/GTS case, GS kept a sub-CA and kept issuing from it under
their own paperwork for customer continuity, which was fine.

Gerv

[Gervase Markham]

On 06/04/17 18:42, Jakob Bohm wrote:
> Here are some ideas for reasonable new/enhanced policies (rough
> sketches to be discussed and honed before insertion into a future
> Mozilla policy version):

I'm not sure what's new or enhanced about them. Our current policies are
not this prescriptive so CAs have more flexibility in how they go about
things, but I believe they preserve the same security invariants.

In general, I suggest that if others have policy problems they see, you
let them draft the solutions? :-)

Gerv

[Peter Kurrasch]

I think Jacob was merely attempting to provide a more thought out alternative to my proposal basically requiring potential CA owners to first be "accepted" into the Mozilla trusted root program. There is some overlap, yes, but the general idea is to be more prescriptive in ownership than the current policy states.

Is there room to expand Mozilla policy in regards to ownership issues?

From: Gervase Markham via dev-security-policy

Sent: Friday, April 7, 2017 4:50 AM To: mozilla-dev-s...@lists.mozilla.org

Reply To: Gervase Markham Subject: Re: Criticism of Google Re: Google Trust Services roots

On 06/04/17 18:42, Jakob Bohm wrote:

> Here are some ideas for reasonable new/enhanced policies (rough
> sketches to be discussed and honed before insertion into a future
> Mozilla policy version):

I'm not sure what's new or enhanced about them. Our current policies are
not this prescriptive so CAs have more flexibility in how they go about
things, but I believe they preserve the same security invariants.

In general, I suggest that if others have policy problems they see, you
let them draft the solutions? :-)‎

Gerv