Relevance of non-repudiation flag in cert generation config

[wing-utm-sharing-airspace]

Wing's understanding is that the InterUSS make certs script: deploy/infrastructure/dependencies/terraform-commons-dss/templates/make-certs.sh.tmp

uses configuration flags outlined in: deploy/operations/certificates-management/init.py.

We are interested in the relevance / importance of including non-repudiation

keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment,keyCertSign

Our understanding is that non-repudiation allows for cryptographic security checks to verify proof of origin and data integrity. Some documentation that we have reviewed from Cockroach DB's website mention:

Warning:
The keyUsage and extendedkeyUsage parameters are vital for CockroachDB functions. You can modify or omit other parameters as per your preferred OpenSSL configuration and you can add additional usages, but do not omit keyUsage and extendedkeyUsage parameters or remove the listed usages.

Should USPs have internal processes for generating their own certs, Wing is inquiring:

• What is the importance of non-repudiation? Given that it is enabled in InterUSS's config, is it InterUSS's recommendation that all USPs should have this flag enabled?
• More broadly, does InterUSS have specific technical guidance / recommendations on configs or flags that USPs should have enabled should they choose to generate their certs using methods other than the provided make-certs script?

[the-glu]

Wing's understanding is that the InterUSS make certs script: deploy/infrastructure/dependencies/terraform-commons-dss/templates/make-certs.sh.tmp

uses configuration flags outlined in: deploy/operations/certificates-management/init.py.

There are two sets of scripts that serve different purposes: make-certs.sh is specific to CockroachDB (calling make-certs.py utilizing cockroach cert), while the scripts in certificates-managements are designed for Yugabyte (and are invoked by deploy/infrastructure/dependencies/terraform-commons-dss/templates/dss-certs.sh.tmp).

That being said, both of their official documentations (CockroachDB as previously noted, and Yugabyte here) explicitly recommend setting the keyUsage value exactly as you quoted, including nonRepudiation .

* What is the importance of non-repudiation? Given that it is enabled in InterUSS's config, is it InterUSS's recommendation that all USPs should have this flag enabled?

* More broadly, does InterUSS have specific technical guidance / recommendations on configs or flags that USPs should have enabled should they choose to generate their certs using methods other than the provided make-certs script?

While I can't speak on behalf of InterUSS regarding official recommendations, aligning with each database's specific guide for certificate generation is likely the safest approach. Based on the CockroachDB documentation, nonRepudiation does appear to be a requirement.

[BenjaminPelletier]

While I can't speak on behalf of InterUSS regarding official recommendations, aligning with each database's specific guide for certificate generation is likely the safest approach.

I believe the official general recommendation (not requirement) of InterUSS is to use InterUSS products according to official documentation (that found in InterUSS repositories) for those products. I believe DSS deployment documentation has a number of different supported deployment approaches (e.g., deploying infrastructure manually, AWS via terraform, or GCP via terraform; deploying services via tanka or helm), but I think all of those deployment approaches use certificate generation methods that include nonRepudiation in keyUsage as @the-glu mentioned above. So, if a certificate does not include nonRepudiation, I would expect that certificate was produced using a deployment approach other than those recommended or supported by InterUSS. I, of course, make mistakes and so would welcome correction if an InterUSS-supported process was used to generate such a certificate -- in that case, we could take a look at whether that workflow needs to be adjusted. We're also very interested in hearing if our recommended methods don't meet user needs -- in that case, we would also want to understand and address the gap.

Given that it is enabled in InterUSS's config, is it InterUSS's recommendation that all USPs should have this flag enabled?

I don't think InterUSS can make durable recommendations on specific ways in which users might deviate from our documented processes in general since there are so many potential deviations. If a user had a need that was not met by our products (which include not only the technical software but also the documentation and processes that serve as "human-level source code" as well), we would be eager to hear about that challenge so we could improve our products to meet that need if practical. We try to keep our products flexible to meet a wide range of user needs while remaining within the boundaries of the defined products, but that flexibility does not extend to this flag in the current product if I understand correctly.

More broadly, does InterUSS have specific technical guidance / recommendations on configs or flags that USPs should have enabled should they choose to generate their certs using methods other than the provided make-certs script?

At this time, I do not believe InterUSS recommends or supports any certificate generation method outside the scripts in this repository executed according to the deployment documentation in this repository. If using these scripts according to the deployment documentation does not meet user needs, we would be eager to improve to meet that user need if practical.