> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec....@lists.mozilla.org] On Behalf Of Peter
> Gutmann via dev-security-policy
> Sent: Friday, March 10, 2017 4:15 AM
> To: Gervase Markham <g...@mozilla.org>; Peter Kurrasch
> <fhw...@gmail.com>
> Cc: MozPol <mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots
> Kurrasch via dev-security-policy <dev-security-policy@lists.mozilla.org>
> writes:
> >* Types of transfers:  I don't think the situation was envisioned where
> >a single root would be transferred between entities in such a way that
> >company names and branding would become intermingled.
> This has happened many times in the past, root certs have been sold and re-
> sold for years.

But I read Peter K's nuance as transfer of less than all the roots owned by a 
CA and/or less than all of the roots in a given brand. When GMO bought 
GlobalSign from Ubizen/Cybertrust, the entire brand went and 
GTE/Baltimore/Betrusted remained with Cybertrust. When Verizon transferred to 
DigiCert, the entire browser trust portfolio moved.

> >* Manner of transfer:  As we learned from Ryan H., a second HSM was
> >introduced for the transfer of the private key meaning that for a
> >period of time 2 copies of the private key were in existence.
> I would be surprised if only two copies were in existence, given the value of
> root keys I'd hope CAs have multiple backup copies.

In my past experience, backups, rather than temporary transfer artifacts, are 
logically, physically, and geographically isolated at rest.

CAs that have been going concerns for many years may assume they intend to 
remain the owners of their roots until they expire. A shortcut results, 
certainly in the case of nCipher security worlds, where keys of common purpose 
and policy are mingled on common hardware, logically isolated by distinct m of 
n operator cardsets under an umbrella admin cardset.

By design, that becomes a split between what is transacting and what is not. At 
some point in time, witnessed by an auditor, in an environment secured 
commensurate with the presence of enabled root keys, transferred keys may need 
to be extracted and tested before the original copies are destroyed with 
witness of that destruction and to the satisfaction of the root buyer. During 
that test window, two copies exist.

Two copies should exist for that moment. Hot transfer of root keys from an HSM 
remaining in control of the seller and an HSM leaving with the buyer puts an 
entire PKI at risk. Copy, test, destroy is a recoverable scenario if a bad 
transfer and test occur.
dev-security-policy mailing list

Reply via email to