Add Validation Component Constraints

[Gabeblis]

Committer Notes

Purpose

The purpose of this PR is to add the Validation Component constraints from issue #1156.

Changes

Added 4 constraints:

• component-has-proof-of-compliance-link
• component-has-valid-proof-of-compliance-link
• component-has-validation-reference
• validation-reference-has-correct-format

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]
• Have you added an explanation of what your changes do and why you'd like us to include them?
• If applicable, have all FedRAMP Documents Related to OSCAL Adoption affected by the changes in this issue have been updated.?
• If applicable, does this PR reference the issue it addresses and explain how it addresses the issue?

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

[wandmagic]

<index name="index-system-implementation-component-uuid-validation" target="component[@type='validation']">
        <key-field target="@uuid"/>
      </index>
      <index-has-key name="index-system-implementation-component-uuid-validation" target="component/link[@rel='validated-by']">
        <key-field target="concat('#', @href)"/>
      </index-has-key>
      <index-has-key name="index-system-implementation-component-uuid-validation" target="component/link[@rel='proof-of-compliance']">
        <key-field target="concat('#', @href)"/>
      </index-has-key>

  We either have to campaign to get the index changed upstream
  
  or link to another component by using the RAW UUID

[aj-stein-gsa]

  We either have to campaign to get the index changed upstream
  
  or link to another component by using the RAW UUID

And where did this bit come from, @wandmagic?

[wandmagic]

  We either have to campaign to get the index changed upstream
  
  or link to another component by using the RAW UUID

And where did this bit come from, @wandmagic?

I just wrote it, it would be a fix if component uuid links are indeed supposed to be prefixed with a hash since i believe the upstream constraint is broken

[aj-stein-gsa]

I am sorry it took a while for me to figure this one and not update sooner in the day, @Gabeblis. Apologies. So I reviewed the information at hand, our out-of-band example SSP in Google Drive we are using to coordinate the work, and the upstream NIST documentation.

For now, and I can adjust the AC in the issue, for now we should adjust rel[@link="proof-of-compliance"] to align with upstream documentation and use rel[@link="validation-details"], like so. This approach can work around a conflicting upstream constraint, while also more closely aligning by name with other associated props.

<component uuid="11111111-0000-4000-a000-000000000001" type="hardware">
   <title>Product Name</title>
   <description>
      <p>Describe the product's function.</p>
   </description>
   <link rel="validation" href="#22222222-0000-4000-a000-000000000002" />
   <status state="operational" />
</component>
<component uuid="22222222-0000-4000-a000-000000000002" type="validation">
   <title>Validation Name</title>
   <description>
      <p>Describe the validation.</p>
   </description>
   <prop name="validation-type" value="fips-140-2" />
   <prop name="validation-reference" value="xxxx" />
   <link rel="validation-details" href="https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/xxxx" />
   <status state="operational" />
</component>

Whether or not the original link[@rel] is more appropriately named, I will file an upstream issue and stick with that for now, let's move forward with this approach.

[wandmagic]

I am sorry it took a while for me to figure this one and not update sooner in the day, @Gabeblis. Apologies. So I reviewed the information at hand, our out-of-band example SSP in Google Drive we are using to coordinate the work, and the upstream NIST documentation.

For now, and I can adjust the AC in the issue, for now we should adjust rel[@link="proof-of-compliance"] to align with upstream documentation and use rel[@link="validation-details"], like so. This approach can work around a conflicting upstream constraint, while also more closely aligning by name with other associated props.

<component uuid="11111111-0000-4000-a000-000000000001" type="hardware">
   <title>Product Name</title>
   <description>
      <p>Describe the product's function.</p>
   </description>
   <link rel="validation" href="#22222222-0000-4000-a000-000000000002" />
   <status state="operational" />
</component>
<component uuid="22222222-0000-4000-a000-000000000002" type="validation">
   <title>Validation Name</title>
   <description>
      <p>Describe the validation.</p>
   </description>
   <prop name="validation-type" value="fips-140-2" />
   <prop name="validation-reference" value="xxxx" />
   <link rel="validation-details" href="https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/xxxx" />
   <status state="operational" />
</component>

Whether or not the original link[@rel] is more appropriately named, I will file an upstream issue and stick with that for now, let's move forward with this approach.

yes this is better than conforming to the broken upstream constraint

[Gabeblis]

I am sorry it took a while for me to figure this one and not update sooner in the day, @Gabeblis. Apologies. So I reviewed the information at hand, our out-of-band example SSP in Google Drive we are using to coordinate the work, and the upstream NIST documentation.

For now, and I can adjust the AC in the issue, for now we should adjust rel[@link="proof-of-compliance"] to align with upstream documentation and use rel[@link="validation-details"], like so. This approach can work around a conflicting upstream constraint, while also more closely aligning by name with other associated props.

<component uuid="11111111-0000-4000-a000-000000000001" type="hardware">
   <title>Product Name</title>
   <description>
      <p>Describe the product's function.</p>
   </description>
   <link rel="validation" href="#22222222-0000-4000-a000-000000000002" />
   <status state="operational" />
</component>
<component uuid="22222222-0000-4000-a000-000000000002" type="validation">
   <title>Validation Name</title>
   <description>
      <p>Describe the validation.</p>
   </description>
   <prop name="validation-type" value="fips-140-2" />
   <prop name="validation-reference" value="xxxx" />
   <link rel="validation-details" href="https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/xxxx" />
   <status state="operational" />
</component>

Whether or not the original link[@rel] is more appropriately named, I will file an upstream issue and stick with that for now, let's move forward with this approach.

I implemented your suggested approach, and the doc-available function doesn't seem to like this URL: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4811. Not sure if you have any insight as to why that might be

[aj-stein-gsa]

I implemented your suggested approach, and the doc-available function doesn't seem to like this URL: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4811. Not sure if you have any insight as to why that might be

One of the things I noticed from our use of GHA daily over the last few years is problem with egress traffic (from GHA to the outside hosts, that means in github.com even but also nist.gov and anywhere outside the network of the GHA runner) has occassional drops or blocking.

Sometimes, that could be the cause of filtering on the GHA side. Other times, especially with csrc.nist.gov and other DOC hosts, I know they have a centralized hosting system that has network problems or maintenance windows (we used to check links upstream in OSCAL on a schedule; you'd be surprised that link failures en masse happened with that every few days).

Let's re-run the test and see what happens.

[aj-stein-gsa]

@Gabeblis rebase and we can merge this PR in, thank you, and nice work as always.

[Rene2mt]

Needs a rebase, but aside from that, this is good to go.

[Rene2mt]

Nice work!