Multiple responses:
1. Thank you Doug, Tim, and Yongqiang for your comments, questions, and suggestions. Jeff Ward - can you respond for the WT Task Force? 2. Other Forum members - now is the time to review these proposed new WTCA audit requirements, and submit your own comments. Some version may apply to your operations very soon. 3. On Tim's point - We have three choices: (a) approve these WTCA amendments now and stop, (b) approve these WTCA amendments now and later add substantive requirements on the same topics to the BRs (which will then cause amendment of the BR WebTrust audit criteria, and perhaps removal of the new WTCA audit requirements on the same subject - 4.5, 4.9, and 4.10), or (c) don't approve the new WTCA requirements, add requirements to the BRs, and then add to the BR Webtrust audit requirements. I would favor (b) - approve these WTCA amendments now (as they may be edited by this process) to deal with the situation now, but ask the NetSec WG to create new substantive requirements that can be added back into WebTrust and ETSI later. That process could take some time, and it would probably be good to have audit requirements now around key destruction and transportation. From: Tim Hollebeek [mailto:[email protected]] Sent: Friday, August 4, 2017 7:05 AM To: Doug Beattie <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]>; Kirk Hall <[email protected]> Subject: [EXTERNAL]RE: [cabfpub] Need two endorsers for Ballot 211 - Resolution of Approval for WTCA v2.1 Changes I have spent literally weeks of my life listening to and participating in discussions about the subtleties of transportation of key fragments by different carriers, at different times, signed for by different people, etc etc etc and there are tons of landmines in that area. In addition to the one Doug mentioned, sending them at different times does not guarantee they arrive at different times; they are likely to end up alone in a mailroom under one person's control. There is also no requirement of any labeling, identification, or authentication of the fragments, to prevent me from substituting a non-tampered fragment of my choice for the original fragment. As another example, "physically secure site" in 4.5.2 is operationally meaningless without a definition or requirements. I'm sitting in my office right now and I'm feeling pretty physically secure. Can I destroy keys here? Who knows. This is another point where entire standards have been written on the subject (ISO 13491 Annex H). We have no requirements AT ALL for physical security for locations where CA operations are being performed (something that should be fixed). It seems odd to have vague lip service to physical security around key destruction when we have no requirements for it for key use. The entire subject of secure key transport is exceptionally complicated, and entire sections of other standards documents have pages and pages of requirements to address it (see, for example, X9.24 part 1). I'm not sure it's a good idea to have an explicit list of illustrative controls that as far as I can see do not map back to any explicit minimum requirements in the BRs. Especially since arbitrarily picking and choosing from the illustrative controls is extremely unlikely to produce a process that has the desired security properties. The entire document reads like an attempt to provide requirements that are missing from the BRs, and I don't think that's a good strategy for filling the holes where the BRs unfortunately are silent. I've opined before that the BRs are unfortunately quite inadequate in providing a reasonable set of minimum requirements to assure that CA systems and keys are reasonably protected throughout their lifecycle. I personally think that is something that should be addressed as part of the replacement of the Network Security Guidelines by the new working group, rather than an effort like this. I see this document as more of a useful contribution towards that effort. The BRs really should address appropriate minimum security requirements for CAs, not just the minutiae of what is or is not allowed in a particular certificate. That said, I get the motivation. What we currently have is nothing. Is this "something" better than our current "nothing"? Or are we better off being silent and encouraging CAs to consult existing industry best standards and other standards documents? It's not clear. -Tim From: Public [mailto:[email protected]] On Behalf Of Doug Beattie via Public Sent: Friday, August 4, 2017 7:13 AM To: Kirk Hall <[email protected]<mailto:[email protected]>>; CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>> Subject: Re: [cabfpub] Need two endorsers for Ballot 211 - Resolution of Approval for WTCA v2.1 Changes Kirk, This is very comprehensive and detailed, nice work to those involved!. I have two minor questions. Item 4.5.13 says: "The CA follows a CA key destruction script for key destruction ceremonies that includes the following:" (then lists 8 numbered items). - Are all 8 of these items REQUIRED as part of the script, or is this a guide that you "should" include them if they are applicable? The reason I ask is that you might destroy keys without zeroization of the HSM. This section seems more focused on how to destroy HSMs vs keys, is that the intent of 4.9.5? If so, then maybe a different intro sentence might be needed to indicate that. Also, item e) isn't totally clear about what is needed or recorded: "physical security requirements for the ceremony location (e.g., barriers, access controls and logging controls);" Item 4.9.5 says this regarding transport of key fragments: "if transported by common carrier, each fragment is sent using a different common carrier at different times. Shipments require signature service, tracking, and are insured." - Is using a different common carrier for each fragment a requirement? There may not be a sufficient number of reliable carriers with these requirements to ship all fragments. Doug From: Public [mailto:[email protected]] On Behalf Of Kirk Hall via Public Sent: Thursday, August 3, 2017 4:45 PM To: CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>> Subject: [cabfpub] Need two endorsers for Ballot 211 - Resolution of Approval for WTCA v2.1 Changes Per our discussion on the CA/Browser Forum teleconference today, here is Ballot 211. Are there two endorsers for this? BALLOT 211 - Resolution of Approval for WTCA v2.1 Changes Type of Ballot: Resolution of Approval of Forum Members only, and not a Draft Guideline Ballot or Final Maintenance Guideline Ballot. The following motion has been proposed by Kirk Hall of Entrust Datacard and endorsed by the following CA/B Forum member representatives: XXXX and YYYY to introduce a Resolution of Approval for WebTrust for CAs v2.1 Changes, as described in the Ballot. Purpose of Ballot: The WebTrust Task Force (TF) is ready to adopt changes to WebTrust for CAs Sec. 4.5 on CA key archival and destruction and new sections 4.9 and 4.10 on CA key transportation and CA key migration, as it has been seeing a number of open questions in those areas. However the Task Force does not ordinarily create draft requirements, but instead typically relies on requirements from other credible sources (such as ISO 21188 for the original WebTrust for CAs in 2000) and then creates related audit criteria. The Task Force has not asked the Forum to add the Sec. 4.5-4.10 changes to the Baseline Requirements or adopt them in a new formal Forum requirements document, but would like the Forum to formally approve the new audit criteria in a Forum Ballot. This Ballot was drafted in response. --Motion Begins-- RESOLUTION OF APPROVAL The Members of the CA/Browser Forum have reviewed the proposed changes to the language of Section 4.5 and the new language of Sections 4.9 and 4.10 in the draft Trust Service Principles and Criteria for Certification Authorities (also known as WebTrust for CAs) version 2.1, and hereby APPROVE the changes and new language and recommend that they be ADOPTED by the WebTrust Task Force (as the language in these sections may be changed from time to time by the WebTrust Task Force in the future, in the Task Force's sole discretion) in the final version of WebTrust for CAs version 2.1 and subsequent versions. --Motion Ends-- BALLOT 211 - Resolution of Approval for WTCA v2.1 Changes Start time (22:00 UTC) End time (22:00 UTC) Discussion (7 to 14 calendar days) [date] [date] Vote for approval (7 calendar days) [date] [date] If vote approves ballot: Review Period - Not applicable.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
