Doesn't that seem to favor incumbents such as OATI? How would a new CA demonstrate this via previous audits?
Isn't it far better for OATI to use that time to establish a solution that segments out those PKIs as appropriate, to separate those of the Web PKI from those aforementioned other standards? On Mon, May 14, 2018 at 10:26 PM, Patrick Tronnier via Public < [email protected]> wrote: > Hi Tim, > > > > OATI operates in an industry where the changes proposed to Section 2g iv. > (If passwords are required to be changed periodically, that period SHOULD > be at least two years. Effective April 1, 2020, if passwords are required > to be changed periodically, that period SHALL be at least two years.) > conflict with multiple industry standards (i.e. NERC CIP, NAESB WEQ-12, > FedRAMP, etc.). > > > > To avoid this auditing nightmare would you consider a slight change in the > wording of Ballot 221? > > > > Perhaps “If passwords are required to be changed periodically, that period > SHOULD be at least two years. Effective April 1, 2020, if passwords are > required to be changed periodically, that period SHALL be at least two > years *unless previous audits prove conflict with other password > standards*." > > > > Thanks > > > > With kind regards, > > > > Patrick Tronnier > > Principal Security Architect & > > Sr. Director of Quality Assurance & Customer Support > > Phone: 763.201.2000 > > Direct Line: 763.201.2052 > > Open Access Technology International, Inc. > > 3660 Technology Drive NE, Minneapolis, MN > > > > CONFIDENTIAL INFORMATION: This email and any attachment(s) contain > confidential and/or proprietary information of Open Access Technology > International, Inc. Do not copy or distribute without the prior written > consent of OATI. If you are not a named recipient to the message, please > notify the sender immediately and do not retain the message in any form, > printed or electronic. > > > > *From:* Public [mailto:[email protected]] * On Behalf Of *Tim > Hollebeek via Public > *Sent:* Monday, May 14, 2018 7:32 AM > *To:* Tim Hollebeek <[email protected]>; CA/Browser Forum Public > Discussion List <[email protected]> > *Subject:* Re: [cabfpub] Ballot 221 v3: Two-Factor Authentication and > Password Improvements > > > > Ok, the person I was waiting for had no comments. I will probably start > the voting period > > tomorrow. > > > > *From:* Public [mailto:[email protected] > <[email protected]>] *On Behalf Of *Tim Hollebeek via Public > *Sent:* Friday, May 4, 2018 3:49 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Subject:* [cabfpub] Ballot 221 v3: Two-Factor Authentication and > Password Improvements > > > > Unchanged from v2. Refreshing time period so it doesn’t expire while I’m > on PTO. > > > > Still waiting for comments from one person. Any other comments also > welcome. > > > > -Tim > > > > Ballot 221: Two-Factor Authentication and Password Improvements > > > > Purpose of Ballot: The Network Security Working Group met a number of > times to > > improve the Network Security Guidelines requirements around authentication, > > specifically by requiring two-factor authentication, and improving the > password > > requirements in line with more recent NIST guidelines. > > > > While CAs are encouraged to improve their password requirements as soon as > > possible, a two year grace period is being given to allow organizations to > > develop and implement policies to implement the improved requirements, > especially > > since some organizations may have to simultaneously comply with other > > compliance frameworks that have not been updated yet and are based on > older NIST > > guidance about passwords. > > > > The following motion has been proposed by Tim Hollebeek of DigiCert and > endorsed > > by Dimitris Zacharopoulos of Harica and Neil Dunbar of TrustCor. > > > > — MOTION BEGINS – > > > > This ballot modifies the “Network and Certificate System Security > Requirements” > > as follows, based upon Version 1.1: > > > > In the definitions, add a definition for Multi-Factor Authentication: > > > > "Multi-Factor Authentication: An authentication mechanism consisting of > two or > > more of the following independent categories of credentials (i.e. factors) > to > > verify the user’s identity for a login or other transaction: something you > know > > (knowledge factor), something you have (possession factor), and something > you > > are (inherence factor). Each factor must be independent. > Certificate-based > > authentication can be used as part of Multifactor Authentication only if > the > > private key is stored in a Secure Key Storage Device." > > > > Capitalize all instances of the defined term "Multi-Factor Authentication". > > > > Add a definition for Secure Key Storage Device: > > > > "Secure Key Storage Device: A device certified as meeting at least FIPS > 140-2 > > level 2 overall, level 3 physical, or Common Criteria (EAL 4+)." > > > > In section 1.j., capitalize Multi-Factor Authentication, and strike the > > parenthetical reference to subsection 2.n.(ii). > > > > In section 2.f., add "(for accountability purposes, group accounts or > shared > > role credentials SHALL NOT be used)" after "authenticate to Certificate > Systems". > > > > Change section 2.g. to read: > > > > "g. If an authentication control used by a Trusted Role is a username and > password, > > then, where technically feasible, implement the following controls: > > i. For accounts that are accessible only within Secure Zones > or High Security > > Zones, require that passwords have at least twelve (12) > characters; > > ii. For authentications which cross a zone boundary into a > Secure Zone or High > > Security Zone, require Multi-Factor Authentication. For > accounts accessible > > from outside a Secure Zone or High Security Zone require > passwords that have > > at least eight (8) characters and are not be one of the > user's previous > > four (4) passwords; and implement account lockout for > failed access attempts > > in accordance with subsection k; > > iii. When developing password policies, CAs SHOULD take into > account the password > > guidance in NIST 800-63B Appendix A. > > iv. If passwords are required to be changed periodically, that > period SHOULD be > > at least two years. Effective April 1, 2020, if passwords > are required to > > be changed periodically, that period SHALL be at least two > years." > > > > In section 2.h., change "Require" to "Have a policy that requires" > > > > In section 2.i., change "Configure" to "Have a procedure to configure" > > > > Change section 2.k. to read: > > > > "k. Lockout account access to Certificate Systems after no more than five > (5) failed > > access attempts, provided that this security measure: > > i. is supported by the Certificate System, > > ii. Cannot be leveraged for a denial of service attack, and > > iii. does not weaken the security of this authentication control;" > > > > Change section 2.n. to read: > > > > "Enforce Multi-Factor Authentication for all Trusted Role accounts on > Certificate > > Systems (including those approving the issuance of a Certificate, which > equally > > applies to Delegated Third Parties) that are accessible from outside a > Secure Zone > > or High Security Zone; and" > > > > — MOTION ENDS – > > > > The procedure for approval of this ballot is as follows: > > > > Discussion (7+ days) > > > > Start Time: 2018-03-28 15:00:00 EDT > > > > End Time: after 2018-05-11 15:00:00 EDT > > > > Vote for approval (7 days) > > > > Start Time: TBD > > > > End Time: TBD > > > > *From:* Public [mailto:[email protected] > <[email protected]>] *On Behalf Of *Tim Hollebeek via Public > *Sent:* Wednesday, March 28, 2018 12:26 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Subject:* [cabfpub] Ballot 221: Two-Factor Authentication and Password > Improvements > > > > > > Ballot 221: Two-Factor Authentication and Password Improvements > > > > Purpose of Ballot: The Network Security Working Group met a number of > times to > > improve the Network Security Guidelines requirements around authentication, > > specifically by requiring two-factor authentication, and improving the > password > > requirements in line with more recent NIST guidelines. > > > > While CAs are encouraged to improve their password requirements as soon as > > possible, a two year grace period is being given to allow organizations to > > develop and implement policies to implement the improved requirements, > especially > > since some organizations may have to simultaneously comply with other > > compliance frameworks that have not been updated yet and are based on > older NIST > > guidance about passwords. > > > > The following motion has been proposed by Tim Hollebeek of DigiCert and > endorsed > > by Dimitris Zacharopoulos of Harica and Neil Dunbar of TrustCor. > > > > — MOTION BEGINS – > > > > This ballot modifies the “Network and Certificate System Security > Requirements” > > as follows, based upon Version 1.1: > > > > In the definitions, add a definition for Multifactor Authentication: > > > > "Multi-Factor Authentication: An authentication mechanism consisting of > two or > > more of the following independent categories of credentials (i.e. factors) > to > > verify the user’s identity for a login or other transaction: something you > know > > (knowledge factor), something you have (possession factor), and something > you > > are (inherence factor). Each factor must be independent. > Certificate-based > > authentication can be used as part of Multifactor Authentication only if > the > > private key is stored in a Secure Key Storage Device." > > > > Add a definition for Secure Key Storage Device: > > > > "Secure Key Storage Device: A device certified as meeting at least FIPS > 140-2 > > level 2 overall, level 3 physical, or Common Criteria (EAL 4+)." > > > > In section 1.j., capitalize Multi-Factor Authentication, and strike the > > parenthetical reference to subsection 2.n.(ii). > > > > In section 2.f., add "(for accountability purposes, group accounts or > shared > > role credentials SHALL NOT be used)" after "authenticate to Certificate > Systems". > > > > Change section 2.g. to read: > > > > "g. If an authentication control used by a Trusted Role is a username and > password, > > then, where technically feasible, implement the following controls: > > i. For accounts that are accessible only within Secure Zones > or High Security > > Zones, require that passwords have at least twelve (12) > characters; > > ii. For accounts that are accessible from outside a Secure Zone > or High Security > > Zone, require Multi-Factor Authentication, with passwords > that have at least > > eight (8) characters and are not be one of the user's > previous four (4) > > passwords; and implement account lockout for failed access > attempts in > > accordance with subsection k; > > iii. When developing password policies, CAs SHOULD take into > account the password > > guidance in NIST 800-63B Appendix A. > > iv. If passwords are required to be changed periodically, that > period SHOULD be > > at least two years. Effective April 1, 2020, if passwords > are required to > > be changed periodically, that period SHALL be at least two > years." > > > > In section 2.h., change "Require" to "Have a policy that requires" > > > > In section 2.i., change "Configure" to "Have a procedure to configure" > > > > Change section 2.k. to read: > > > > "k. Lockout account access to Certificate Systems after no more than five > (5) failed access attempts, provided that this security measure: > > i. is supported by the Certificate System, > > ii. Cannot be leveraged for a denial of service attack, and > > iii. does not weaken the security of this authentication control;" > > > > Change section 2.n. to read: > > > > "Enforce Multi-Factor Authentication for all Trusted Role accounts on > Certificate > > Systems (including those approving the issuance of a Certificate, which > equally > > applies to Delegated Third Parties) that are accessible from outside a > Secure Zone > > or High Security Zone; and” > > > > — MOTION ENDS – > > > > The procedure for approval of this ballot is as follows: > > > > Discussion (7+ days) > > > > Start Time: 2018-03-28 15:30:00 EDT > > > > End Time: after 2018-04-04 15:30:00 EDT > > > > Vote for approval (7 days) > > > > Start Time: TBD > > > > End Time: TBD > > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
