On 07/03/2017 18:29, Ryan Hurst wrote:
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.
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.
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.
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.
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
