Question about section 2.2.5

[Pedro FUENTES]

Hello,

I’d appreciate is someone can refresh me about what was the rational for this: “The CA SHALL NOT require periodic password changes with a period less than two (2) years.”

Thanks!

Pedro

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

[Roman Fischer]

Hi Pedro,

 

Current NIST recommendations are to use loooong passwords and NOT change them too frequently. 😊

 

-Roman

--
You received this message because you are subscribed to the Google Groups "NetSec WG - Public (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netsec+un...@groups.cabforum.org.
To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/474DBF19-CB66-4065-89C2-8E28CAC8F22B%40wisekey.com.

[Pedro FUENTES]

OK, fair enough, but I don’t get why such “recommendation” is set as a “SHALL NOT” in the NetSec...

On 6 Aug 2024, at 09:55, Roman Fischer <roman....@swisssign.com> wrote:

Hi Pedro,

 

Current NIST recommendations are to use loooong passwords and NOT change them too frequently. 😊

 

-Roman

 

From: 'Pedro FUENTES' via NetSec WG - Public (CA/B Forum) <net...@groups.cabforum.org> 
Sent: Dienstag, 6. August 2024 09:47
To: net...@groups.cabforum.org
Subject: [netsec] Question about section 2.2.5

 

Hello,

 

I’d appreciate if someone can refresh me about what was the rational for this: “The CA SHALL NOT require periodic password changes with a period less than two (2) years.”

 

Thanks!

Pedro

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

 

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

 

-- 
You received this message because you are subscribed to the Google Groups "NetSec WG - Public (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netsec+un...@groups.cabforum.org.
To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/474DBF19-CB66-4065-89C2-8E28CAC8F22B%40wisekey.com.

-- 
You received this message because you are subscribed to the Google Groups "NetSec WG - Public (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netsec+un...@groups.cabforum.org.

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/ZR0P278MB0170E42BF0E3172565E91A5BFABF2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Martijn Katerbarg]

I believe the current proposal that is being worked on to revamp that section, changes this to a SHOULD NOT, rather than a SHALL NOT. I don’t have the docs URL here right now though.

Regards,

Martijn

 

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/06A55930-B1D5-467B-9D3F-5113432A914C%40wisekey.com.

[Tony Rutkowski (Contractor)]

Hi Roman,

The CIS Password Policy Guide which is used in conjunction with implementing the Critical Security Controls globally, including the ETSI transpositions, states "change immediately based on events, with a one-year expiration 'backstop' (annual)."  The length and complexity include the additional variable of Multi-Factor Authentication.  See https://learn.cisecurity.org/cis-password-policy-guide-passphrases-monitoring-and-more

best,
tony r

---

From: Roman Fischer
Sent: Tuesday, August 06, 2024 3:55 AM
To: net...@groups.cabforum.org
Subject: [External] [netsec] RE: Question about section 2.2.5

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/ZR0P278MB0170E42BF0E3172565E91A5BFABF2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.

. . . . .

[Ben Wilson]

Check with Tim Hollebeek.  I think he worked on it.

[Tim Hollebeek]

Because forcing people to change their passwords regularly causes them to use weaker passwords, for example by appending the year and just rotating that. I was actually sitting in a talk by Kevin Mitnick where he was complaining about 90 days passwords causing passwords like “Spring2018!” and decided to fix it.

 

Note that this requirement does not preclude changes when there IS a good reason to change it, for example, known or suspected compromise.

 

It just says that if you have a policy mandating password changes after a certain time period for no reason at all, that mandated rotation period must be greater than or equal to two years.

 

-Tim

 

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/CA%2B1gtabs83iWaC%2Bw3daP09E-jy7xzC1JUxP2xooybBOSs1j_NA%40mail.gmail.com.

[Clint Wilson]

Exactly :) 

I don’t have an issue with the current language, precisely because it focuses only on requirements for periodic password rotation and imposes no limitations on changing passwords whenever is necessary for any reason other than “an arbitrary period of time has passed”.

But I think the update Prachi and Dan have been working on, moving this to a SHOULD NOT, is fine too.

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/SN7PR14MB6492F3A69ED92EE0E25F184C83BF2%40SN7PR14MB6492.namprd14.prod.outlook.com.

[Daniel Jeffery]

I'm in meetings, but wanted to point out we've actively discussed this at the last two netsecWG meetings and have a few proposed changes upcoming for 2.2.5 and related. Those are recorded here:
https://docs.google.com/document/d/1h-mk34aypObT-_HdWUAGLrCZGsuvtSFITPTBgsXT83E/edit

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/04A06CE0-AD1C-4DCB-AE96-57CD7E2C22DC%40apple.com.

--

Daniel Jeffery | TLS

fastly.com | @fastly | LinkedIn

[Pedro FUENTES]

While I agree with these reasons, I don’t agree with the “SHALL NOT” linked to two years in particular. 

Certain flexibility to adapt security policies should be allowed here. 

P

Le 6 août 2024 à 18:20, 'Clint Wilson' via NetSec WG - Public (CA/B Forum) <net...@groups.cabforum.org> a écrit :

Exactly :) 

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/04A06CE0-AD1C-4DCB-AE96-57CD7E2C22DC%40apple.com.

[Tim Hollebeek]

Is there a particular need for mandatory password rotation policies less than two years? I want to understand why people need flexibility here.

 

Otherwise, my opinion on whether such policies should be allowed remains unchanged. But that’s just me.

 

-Tim

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/C4339FF8-692A-4C4B-8524-CFDB7AFF885B%40wisekey.com.

[Martijn Katerbarg]

We’ve seen at least one platform which allows a rotation requirement to be set between 30 and 730 days, which with leap years, doesn’t cut it.

 

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/SN7PR14MB6492EA237C07167312C00E1883BF2%40SN7PR14MB6492.namprd14.prod.outlook.com.

[Tobias S. Josefowitz]

On Tue, 6 Aug 2024, 'Martijn Katerbarg' via NetSec WG - Public (CA/B Forum) wrote:

> We've seen at least one platform which allows a rotation requirement to

> be set between 30 and 730 days, which with leap years, doesn?t cut it.

In this example, is it

1) You must force rotation between 30 and 730 days, or
2) If you force rotation, it must be between 30 and 730 days and could not
be e.g. 732?

Tobi

[Tim Hollebeek]

Isn't this all in a section that says "where technically feasible" at the top?

We were aware when writing the password requirements that not all systems
would be able to comply perfectly.

-Tim

> -----Original Message-----
> From: Tobias S. Josefowitz <to...@opera.com>
> Sent: Tuesday, August 6, 2024 1:13 PM
> To: 'Martijn Katerbarg' via NetSec WG - Public (CA/B Forum)
> <net...@groups.cabforum.org>
> Subject: Re: [EXTERNAL]-Re: [netsec] Question about section 2.2.5
>

> --
> You received this message because you are subscribed to the Google Groups
> "NetSec WG - Public (CA/B Forum)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to netsec+un...@groups.cabforum.org.
> To view this discussion on the web visit

> https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/635fc920-
> 5d92-5fca-51ba-2eee31c100c4%40opera.com.

[Martijn Katerbarg]

>Isn't this all in a section that says "where technically feasible" at the top?

Not that I could spot.

 

>1) You must force rotation between 30 and 730 days,

 

This ^^

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/SN7PR14MB6492CA84CBDF47B26523C04E83BF2%40SN7PR14MB6492.namprd14.prod.outlook.com.

 

[Tim Hollebeek]

2(g) in v1.7 of the NCSSRs.

 

It looks like it got lost in the 2.0 re-organization.

 

-Tim

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/SA1PR17MB6503879C54A4F83A23BB1FDBE3BF2%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Daniel Jeffery]

We could add it back in, Tim. We're going to try and incorporate the changes in the document I linked soon. Suggestions are welcome. 
For those requesting access to the document, I'm going ahead and granting to folks that fit the pattern for membership here, but ideally you'd ask David Kluge (or whoever else is appropriate -- David owns the folder) to set you up with access to the Google Drive shared folder for the netsec group: https://drive.google.com/drive/folders/1Yvf-gyLkykwUT3bsGY12XEk0EjxS4MTj

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/SN7PR14MB6492CB2DAD8F365092A4D15B83BF2%40SN7PR14MB6492.namprd14.prod.outlook.com.

[Clint Wilson]

Here’s what was shared in the “NCSSR Changes in Detail” document regarding 2(g) (emphasis added):

This requirement is somewhat awkward in the current document structure, but hopefully fits better within the updated section 2.2.4. The requirement has been moved towards the end of the 2.2 “Access Management” section, as it seemed appropriate to follow Workstation and MFA/MPC requirements, but it’s certainly reasonable that it should be located elsewhere if there are opinions on the matter.

The requirement has also been rephrased into 4 discrete requirements intended to:

1. Remove prose not related to requirements;

2. Reformat to align with draft document style; and

3. Consolidate or remove duplicative requirements

Separately, I’ve included the removal of the clause which currently heavily limits the reliability of the current requirements, i.e. “where technically feasible”.

I would personally not suggest adding this back in; shifting to a SHOULD NOT effectively includes this sentiment (and a bit more) as we’re using RFC 2119 definitions of that phrase:

This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Cheers,

-Clint

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/SN7PR14MB6492CB2DAD8F365092A4D15B83BF2%40SN7PR14MB6492.namprd14.prod.outlook.com.

[Daniel Jeffery]

What is currently in the linked doc puts things in a better place, I think. We came to this with some clarifications and concerns similar to Pedro's as we reviewed the changes form NS03. 

At the last meeting I took an item to combine 2.2.1.2 into 2.2.5, but after taking a few passes and going over it internally here at Certainly, we like it the way it is now. Unless anyone has objections or suggestions, the current version of the google doc is what I'd like to put into a ballot.

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/netsec/B69B827A-EC5D-4ABF-B6E4-5FD63A1EA2B0%40apple.com.

[Daniel Jeffery]

We discussed this further in last week's netsec call. I've put the following PR together that I'd like to move to a ballot. Suggestions, corrections and discussion are welcome.

https://github.com/cabforum/netsec/pull/38/files