This message focuses on [crypto_credential_agility].

Reminder about the CII text:

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

My take is that this one covers both the credentials needed to access remote services by the application AND the credentials used for authentication of others connecting to the application.

1. Correct, no hard coding of passwords within the source code.
2. Good questions on containers. I’m not sure what the answers are.

1. Kubernetes secrets would probably satisfy the requirement.

1. It seems that AAF would be a perfectly reasonable way to satisfy this requirement.

One aspect is that if you have passwords (or hashes of the passwords, etc), should be saved in the a different file from where other configuration values are stored.

Additional discussion is welcome.

                Tony

Question(s), Tony,

. . .

Agility

1.      Are you talking about storing Credentials, etc, of the App itself, or Clients

a.      By “Compile” are you talking about not Hard Coding Passwords in Source (i.e. .js, java, .c, .cpp, whatever) files.

b.      Or are we realizing that Containers essentially Freeze what used to be dynamic configs, so you have to plan for updates.

                                                      i.      Does “Use docker/kubectl Container Copy instructions” meet this goal?

                                                    ii.      The constant Top priority of “Start from Scratch” makes this difficult, of course.

c.       If Client Creds, it should be pointed out that Apps can use Externalization of Client Creds, which is, of course, the point of AAF (sorry for the plug)

. . .

Here are the next few items that I think we need to work on with respect to moving forward with CII badging. These three have lots of projects marked [?] under the Silver level.

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

[crypto_credential_agility]

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replacement them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select 'not applicable' (N/A).

[crypto_verification_private]

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select 'not applicable' (N/A).

As discussed at DDF, the idea is that we would

Week 1

Introduce a topic at the PTL meeting with instructions.

We give stats on how many projects that have answered this question already.

Week 2

One week later, we check to see what progress there is.

Give kudos to those who have made progress.

We file JIRA tickets on those projects that have not given any answer.

Introduce the next topic, etc

Week 3

We bump up the priority on those tickets.

So, for next week’s meeting, here are instructions for [crypto certificate verification]. Comments are welcome.

• This week’s CII issue is

[crypto_certificate_verification]

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select 'not applicable' (N/A).

• Visit your project page, and login. (If necessary, go to bestpractices.coreinfrastructure.org and do a search.)
• Click on the silver button near the top where it says “You can also view your [silver] or [gold] level criteria.”
• Click the [Edit] button at the top.
• Scroll to the bottom and click on the v Security banner. Search for “The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS”
• This question is about places in your software where you invoke external APIs, such as HTTP REST calls or database queries or LDAP.

• If your project software does not make any external API calls, then select “not applicable”

• Click the [N/A] button
• In the description, explain that you do not have any external API calls.
• Include the current date at the end of your explanation, as in [2019/06/24]
• Include a URL to your project’s onap.readthedocs.io page that describes its architecture.

• If your project software does NOT use TLS for ANY of your external API calls, then select “not applicable”.

• Click the [N/A] button
• In the description, explain that you do not have any external API calls.
• Include the current date at the end of your explanation, as in [2019/06/24]
• Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.

• If your project software uses TLS, and its default mode is to do certification verification against a locally maintained list of Certificate Authority certificates.

• Click [Met]
• In the description, explain that you do not have any external API calls.
• Include the current date at the end of your explanation, as in [2019/06/24]
• Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.

• If your project software uses TLS, but its default mode is NOT to do certificate verification against a locally maintained list of Certificate Authority certificates.

• Click [Unmet]
• FILE A JIRA against your project
• In the description, explain what you don’t do
• Include the current date at the end of your explanation, as in [2019/06/24]
• Include a URL to your project’s onap.readthedocs.io page that describes how it uses external APIs.
• Include the JIRA ticket number(s) in your answer.

• If some of your software meets the above but other parts do not:

• Select [Unmet]
• Include an explanation in the description for each part, following the above instructions.

• If some of your software meets the above, but other parts do not use TLS,

• Select [Met]
• Include an explanation in the description for each part, following the aboe instructions.

• VERY IMPORTANT: Click one of the green buttons that say [Save (and exit)] or [Save (and continue)]