<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Here are the draft notes of our meeting this past Thursday on 16-Nov-2017.  Please suggest any changes you feel are necessary.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In attendance:  Ben Wilson, Fotis Loukos, Xiu Lei, Dimitris Zacharopoulos, Neil Dunbar, Tobi Josefowitz, Bruce Morton, Steven Hillier<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The group discussed an email from Josh Aas regarding HSMs to which Fotis had replied.  The email exchange indicated a difference in opinion on how firmware updates could be applied and how that affected compliance and/or FIPS certifications.  When an HSM vulnerability becomes known, the HSM vendor creates an update to firmware, but NIST/CC validation takes time.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>BR Section 6.2.7 (Private Key Storage on Cryptographic Module) currently states, “The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There was some agreement between Fotis and Josh that HSMs should be updated with the latest firmware.  Ben asked for some updated ballot language.  Fotis said that we should use the FIPS 140-2 language and specify FIPS 140  Level 3 in at least these two areas:  Level 3 for physical security of the device and Level 3 for EMI/EMC.  Josh proposes to exclude firmware, “FIPS Level 3 physical device excluding firmware.”  Fotis’ criticism of this approach is that we haven’t defined “physical device excluding firmware.”   Josh will be working on another draft of the ballot.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Regarding the threat modeling subcommittee, Dimitris said that it meets on Wednesdays and continues to make progress.  They have completed Google spreadsheets for threats to Root CA systems.  The group has discussed transferring capabilities in an air-gapped system and the bad USB model.  Next they hope to discuss and address network transfer capabilities, but still in an air-gapped system (the same local area network).  Fotis and Ryan are going to develop a model.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We noted that another subgroup exists that is supposed to be working on passwords.  That group needs to pick the ball up again / pick up the pace of discussion.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There are places in the Network Security Requirements where the term “CA” needs to be changed to “TSP”.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The group next discussed definitions – workstation, account, etc.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>“Workstation” is only used in 2.h and 2.i.  Does “workstation” need to be defined?  And if so, what would that definition be?  Tobi suggested that the concept of the operator of the workstation is more important than the definition of workstation.  The “who” operates this computer is more important.  Dimitris said that a workstation is a client computer that is used by the person to perform that person’s trusted role.  Different roles will have different access.  The same rule is being applied regardless of whether they are vetting agents, CA administrators, sysadmins, etc.  Ben said that editing these sections may require more of an overhaul—it won’t be easy to just replace a few words.  Maybe 2.h. and 2.i  could be merged because they’re similar?  Section 2.h. could be reworded to say that “policy must require ….”  That would require the CA to maintain documentation.  Dimitris noted that 2.i  more likely requires a practice—configure the thing to have an inactivity timeout.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Do auditors have trouble defining the term “workstation”?  Ben envisioned situations where the auditor, in dealing with the CA, might have discussed this and may have needed guidance on what a workstation is, as compared to other computing components.   <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The word “account” is used a few times in the Network Security Requirements.  Disabling of accounts is required upon employee termination.  Changing passwords is required on privileged accounts.  There is a requirement to review all “system accounts”.  Do we need to define “account”?  Dimitris said we should use the phrase “privileged account” instead.  “Privileged accounts” are used by trusted roles to exercise the privileges of a trusted role.  Should we look at our use “Privileged Account” vs lowercase “account” in other places?  Or we could just define “Account” to mean privileged accounts.  We cannot define a word in terms of itself.  So account could be “A location on a network server used to store a computer username, password, and other information.  A user account allows a user to connect ….”  A user account contains information that allows a user to connect to a network resource.  Tobi asked why we feel we need to define the term “account” further?  Ben said that there may be situations where the auditor and the CA are looking for guidance when interpreting the Network Security Requirements.  They could look at the definition and decide on one side or the other of the issue presented (with the help of the definition).  Then, in the future, if they find this doesn’t help them, they can come back and ask us to clarify the requirement more.  Tobi said that we may not know ahead of time the problem that we’re trying to solve.  We can direct them, but if we don’t know which way we anticipate the way that the word “account” would be misunderstood by an auditor, we cannot be sure that we’ll be directing the discussion in the right direction.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Dimitris said that this issue reminds him of the reasons why we went back to the threat assessment approach for the offline root CA issue.  We didn’t know what we were trying to protect against.  So, we went back to identify the threats so that we can tell what these controls are used for.  When you read this intuitively, “accounts that are accessible outside a secure zone” it’s usually remote access, web portal accounts, VPNs, you wouldn’t go so far as to say you mean the HSM accounts.  So, there were some corner cases where some auditors thought that this control should expand to every possible account in a CA system.  Not every account supports these types of protections, protections against reuse, etc.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Should we address the definition of “Zone”?  Zone is defined as “a subset of certificate systems …”  The definition uses the phrase “certificate systems” twice.  Could the second phrase be deleted?  Or do we delete the definition altogether?  There are already good definitions for “Secure Zone” and “High Security Zone”.   We use the phrase “Secure Zones” throughout the NetSec Requirements.  The definition doesn’t imply that there is only one “Secure Zone” – CA systems have multiple Secure Zones.  We could add the phrase “or parts thereof” after “Secure Zone”, to clarify it.  Dimitris suggested that we delete the definition Zone.  Tobi noted that “Zone” isn’t used and that it is always used in conjunction with Secure Zone or High Security Zone.  The group was of consensus that “Zone” could be deleted.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Next meeting we’ll start by discussing 3.e. of the Network Security Requirements (“Certification Authorities and Delegated Third Parties SHALL: … e. Ensure that application and system logs have integrity and are operating properly (the CA or Delegated Third Party MAY use an in-house or third-party audit log reduction and analysis tool);”).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Next meeting in 3 weeks (7-Dec-2017).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Meeting adjourned.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:2.0pt'><b><span style='font-family:"Arial",sans-serif;color:#0174C3'>Ben Wilson, JD, CISA, CISSP<o:p></o:p></span></b></p><p class=MsoNormal style='margin-bottom:2.0pt'><span style='font-family:"Arial",sans-serif;color:#686869'>DigiCert VP Compliance<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:2.0pt'><span style='font-family:"Arial",sans-serif;color:#686869'>+1 801 701 9678<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>