Correct digest lengths

[david-waltermire]

Committer Notes

Based on some testing, the required digest lengths should be twice their current size to be correct. This PR adjusts the values to be the correct size.

Resolves #2053

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers"?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?
• Have you updated all OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the docs/content directory of your branch.

[aj-stein-gsa]

@david-waltermire, per our desire to coordinate a patch release with NIST, can we please target this PR on main, not develop? I will ping you in an upcoming discussion topic. Thanks!

[wendellpiez]

That would be fine with me (main not develop) although I just stated the opposite (over on #2069) - shows what I know.

As for the merits of the PR, 👍 to backward-compatible improvements and corrections - if the constraint is to be included at all it should be correct. (Removing it into a different layer of constraint checking is also a good solution in my view.)

[david-waltermire]

According to the contributing guidelines it looks like I should target release-1.1 for a patch release. I am going to rebase and change the PR to point there.

[iMichaela]

According to the contributing guidelines it looks like I should target release-1.1 for a patch release. I am going to rebase and change the PR to point there.

This is correct and everything we merged already in develop was staged for the v1.1.3 patch release, hence the request to submit the PRs towards develop branch, so we do not need to rebase develop to release 1.1.3. There are no new features or models added, but dependency updates are also a needed. There is one SAP constraints bug #2059 that must be also fixed with the v1.1.3. Once we decide the direction to go for #2059, will implement it, asap, test it and release 1.1.3.

[david-waltermire]

According to the contributing guidelines it looks like I should target release-1.1 for a patch release. I am going to rebase and change the PR to point there.

This is correct and everything we merged already in develop was staged for the v1.1.3 patch release, hence the request to submit the PRs towards develop branch, so we do not need to rebase develop to release 1.1.3. There are no new features or models added, but dependency updates are also a needed. There is one SAP constraints bug #2059 that must be also fixed with the v1.1.3. Once we decide the direction to go for #2059, will implement it, asap, test it and release 1.1.3.

I am happy to rebase to develop if that is what you want me to do.

I do want to point out that what you are suggesting is not consistent with the practices for a patch release identified in the contributing guidelines for the repository which states:

Contributions can be made to the following branches in this repository:

• release-*: The release branches are used to provide patches to a major or minor version of OSCAL. The branches are named release-major.minor. You should provide changes only to the highest numbered minor release for a given major release. Patch releases are made more frequently than major or minor releases.
• develop: This branch is used to queue changes for the next major/minor release of OSCAL. A major/minor release will result in the creation of a new release branch, once the development has been completed and the update is to be staged for release.

Inconsistent application of these guidelines makes the process confusing, difficult to predict, and more labor intensive for contributors. It would be helpful to have a more consistent approach.

[iMichaela]

The values for the hashes are correct now per NIST examples:
https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/examples/sha224.pdf
https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/examples/sha256.pdf
https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/examples/sha384.pdf
https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/examples/sha512.pdf

The proposed IDs for the constraints are new, but they are not causing OSCAL backwards compatibility issues per local testing.