Hi Jeff,
Since I am not a native English speaker, I will try to offer my
perspective on some of the terms used in this document so here is my 2
cents. "CA Key Transportation" was the section I had some difficulty
reading but the explanatory guidance is very helpful. It is a real
challenge for both Auditors and CAs to meaningfully assess the security
risks between cases where the CA private key is backed up "using
approved methods from the hardware vendor" and CA's methods that perform
the same "approved methods" (key wrapping, further splitting and so on).
In other words, a CA's methods might be above and beyond the vendor
specific methods, which is a good thing.
Here are some cases that might be considered for the "CA Key
Transportation":
1. Relocation of an HSM that already contains the CA private keys. In
this scenario, CA private keys are always in a de-activated state
and require activation material, as explained in 4.9. The
description of 4.9 "CA Key Transportation" seems to cover all
critical steps. I would prefer the use of the term "relocation" for
this particular scenario.
2. Relocation of an HSM that doesn't contain the CA private keys (keys
are deleted prior to transportation). This scenario is probably
covered under some other criteria for secure relocation of equipment.
3. Transportation of an HSM vendor-specific encrypted CA private key
backup. In this scenario, this vendor-specific encrypted backup can
be restored in an HSM of the same vendor, using the backup file and
the backup key (usually kept separately). I don't know if there is a
specific Webtrust terminology that describe this
"encryption/decryption backup key", it might be covered under the
"activation material" which refers to "passwords, PINs and/or tokens
(i.e. m of n tokens) needed to access and/or activate the CA key on
the secure cryptographic module", but in reality you cannot
activate/access the CA private key if you only have the decryption
"backup key". IMHO, this type of "transportation" is not fully
covered under the 4.9 "CA Key Transportation" section. If you
consider further splitting of the activation material using
transforms like "all-or-nothing
<https://en.wikipedia.org/wiki/All-or-nothing_transform>", then you
might want to allow cases where you don't need multi-person control
to constantly monitor these fragments during transit. Of course,
these fragments are never transferred altogether, they should be
considered "CA private key material" that will require "activation
material" to be usable again.
Section 4.10 "CA Key Migration" seems to cover all critical steps.
Hope this helps.
Dimitris.
On 23/6/2017 8:22 μμ, Jeff Ward via Public wrote:
As mentioned during our presentation at the face-to-face meeting in
Berlin, the WebTrust for Certification Authorities Task Force has
proposed new criteria be added to WebTrust for Certification
Authorities to be included in a new version, 2.1. The changes are to
cover event based activities that are not currently addressed in the
WebTrust criteria and would add consistency in their treatment for
auditors and CAs alike. Since they are event based, they should not
cause any concerns for CAs when they become effective. Specifically,
the added criteria relate to the following:
4.5 CA Key Archival and Destruction
4.9 CA Key Transportation
4.10 CA Key Migration
Please see the attached document. It is in a tracked changes format
so you can see what new criteria we are suggesting in 4.5, as well as
the addition of sections 4.9 and 4.10. The criteria that are included
today are based on ISO 21188. Since these proposed changes are not
part of that standard, we need a public group (CABF qualifies as such)
to approve the criteria.
We would appreciate the CABF’s review and balloting to approve these
changes as soon as possible so we can release the new version, 2.1.
Please let me know if you have any questions.
On behalf of the WebTrust for Certification Authorities Task Force,
Jeff Ward
Chairman
*Jeff Ward, CPA, CGMA, CITP, CISA, CISSP, CEH*
Office Managing Partner & National Managing Partner Third Party
Attestation Services
(SOC/WebTrust/Cybersecurity)
314-889-1220 (Direct) 347-1220 (Internal)
314-889-1221 (Fax)
[email protected] <mailto:[email protected]>
*BDO*
101 S Hanley Rd, #800
St. Louis, MO 63105
UNITED STATES
314-889-1100
_www.bdo.com <http://www.bdo.com>_
/Please consider the environment before printing this e-mail/
BDOC Networking Award
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
