Hi Tim. Sorry for the delayed response.  The concern is not the finite number 
of years but the fact that it would be a requirement vs. a recommendation or 
best practice.  The concern is NOT with a 2 year transition timeline but the 
fixed minimum timeline for life of a password.  The concerns I initially 
brought up are still not directly addressed.  Specifically:


  *   What about when a CA employee leaves who knows the password which 
requires it to be change in less than two years?
  *   What about if the password is compromised and needs to be changed in less 
than two years?
  *   How would auditors verify and prove that a CA did not change a password 
more frequently than two years? This is trying to prove a negative.
  *   Also, what about the use of Just In Time (JIT) admin where all CA access 
is done with a session password that is deleted when the session ends. So we 
literally have passwords that last minutes. Once the session ends the password 
is useless.

In summary:

  *   2 years is probably fine for implementation of whatever password change 
recommendation is put in place but we don’t think it should be a requirement.  
Any prescriptive language around password lifecycles should be avoided.
  *   Any wording that requires a password NOT change within a certain period 
of time is problematic as there are numerous exceptions and auditing will be a 
challenge.

Perhaps language such as this would work:  “Frequent password changes have been 
shown to cause users to select less secure passwords.  For passwords associated 
with CAs, key materials and related systems, it is recommended that the CA set 
password change targets of 2 years or more to reduce the risk of insecure 
passwords being used to control and operate CAs.”  However the use of JIT may 
make this problematic as well.

Thanks, Mike
From: Tim Hollebeek <[email protected]>
Sent: Saturday, July 14, 2018 12:10 AM
To: Mike Reilly (GRC) <[email protected]>; CA/Browser Forum Public 
Discussion List <[email protected]>; Wayne Thayer <[email protected]>
Cc: [email protected]
Subject: RE: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network 
Security Guidelines

Mike,

Is there a finite number of years larger than two you could get behind?

-Tim

From: Mike Reilly (GRC) [mailto:[email protected]]
Sent: Friday, July 13, 2018 7:39 PM
To: Tim Hollebeek 
<[email protected]<mailto:[email protected]>>; CA/Browser 
Forum Public Discussion List <[email protected]<mailto:[email protected]>>; 
Wayne Thayer <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network 
Security Guidelines

Tim and Wayne, I believe making this a requirement will be problematic as I 
commented on with the original ballot (at bottom of thread).  So language would 
need to be as shown below. Thanks, Mike

  iv.         Frequent password changes have been shown to cause users to 
select less
               secure passwords.  If the CA has any policy that specifies 
routine periodic password changes,
               that period SHOULD NOT be less than two years.  Effective April 
1, 2020,
               if the CA has any policy that requires routine periodic password 
changes, that period SHALL NOT
               be less than two years."

From: Public <[email protected]<mailto:[email protected]>> 
On Behalf Of Tim Hollebeek via Public
Sent: Friday, July 13, 2018 3:49 PM
To: Wayne Thayer <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; CA/Browser 
Forum Public Discussion List <[email protected]<mailto:[email protected]>>
Subject: Re: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network 
Security Guidelines

Works for me.  I’ll update the ballot.

-Tim

From: Wayne Thayer [mailto:[email protected]]
Sent: Friday, July 13, 2018 12:24 PM
To: Tim Hollebeek 
<[email protected]<mailto:[email protected]>>
Cc: CA/Browser Forum Public Discussion List 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Subject: Re: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network 
Security Guidelines

On Fri, Jul 13, 2018 at 4:50 AM Tim Hollebeek 
<[email protected]<mailto:[email protected]>> wrote:
Do you have proposed modifications that would address these questions?  I would 
be happy to incorporate them.


How about this:

  iv.         Frequent password changes have been shown to cause users to 
select less
               secure passwords.  If the CA has any policy that specifies 
routine periodic password changes,
               that period SHOULD NOT be less than two years.  Effective April 
1, 2020,
               if the CA has any policy that requires routine periodic password 
changes, that period SHALL NOT
               be less than two years."

From: Wayne Thayer [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, July 12, 2018 7:35 PM
To: Tim Hollebeek 
<[email protected]<mailto:[email protected]>>; CA/Browser 
Forum Public Discussion List <[email protected]<mailto:[email protected]>>
Cc: Adriano Santoni 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Subject: Re: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network 
Security Guidelines

How are the concerns that were raised by Microsoft (copied below for reference) 
addressed in this version? If the intent is for the language in section 2.g(iv) 
to only apply to periodic, policy-driven password changes and not to prevent 
event-driven changes, I think that should be clarified.

* How would auditors verify and prove that a CA did not change a password more 
frequently than two years? This is trying to prove a negative.
* What about when a CA employee leaves who knows the password which requires it 
to be change in less than two years?
* What about if the password is compromised and needs to be changed in less 
than two years?

- Wayne

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to