Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Profile Resolution Specification for Back-Matter Resources Only with rlinks? #1140

Closed
aj-stein-nist opened this issue Feb 15, 2022 · 5 comments · Fixed by #1172
Closed

Profile Resolution Specification for Back-Matter Resources Only with rlinks? #1140

aj-stein-nist opened this issue Feb 15, 2022 · 5 comments · Fixed by #1172
Assignees
@stephenbanghart
Labels
bug Profile Resolution Issues relating to profile resolution.
Milestone
OSCAL 1.0.2

Comments

@aj-stein-nist
Copy link
Contributor

Describe the bug

The current draft of the profile resolution spec in #1089 (and currently published on the website, before the #1089 PR) suggest that given an internal reference to a resource in the profile's import @href, the specification states that it resolve back-matter resource with rlink @hrefs, but it is implied base64 (and its @filename) can be ignored.

In the context of the Import Phase, internal references will only appear as a reference to a profile or catalog that is in the resources section of the source. When tools encounter such a reference, they MUST locate the object in resources with the matching ID value, and resolve the import using the rlinkURI and the above resolution requirements.

OSCAL/src/specifications/profile-resolution/profile-resolution-specml.xml

Lines 289 to 316 in 7e0ec36

<section id="internalref">
<head>Internal References</head>
<p>URI Fragments in OSCAL represent internal references to other OSCAL objects in the same document. These references follow the pattern of <code>#{{objectID}}</code>. For example, the URI Fragment <code>#param1</code> is referencing the Parameter with unique ID <code>param1</code>.</p>
<p><req level="must" id="req-internal">In the context of the Import Phase, internal references will only appear as a reference to a profile or catalog that is in the <src>resources</src> section of the source. When tools encounter such a reference, they MUST locate the object in <src>resources</src> with the matching ID value, and resolve the import using the
<src>rlink</src> URI and the above resolution requirements.
</req></p>
<p><req level="must" id="req-internal-error">If the object fetched cannot be found or is not a valid OSCAL object, the tool MUST cease processing and provide an error.</req></p>
<tagging whose="source_profile">
<![CDATA[
profile:
metadata: ~
imports:
- href: "#nist-sp800-53_catalog"
include-controls: ${{ list of selected controls }}
# Content Elided
backmatter:
resources:
- uuid: "nist-sp800-53_catalog"
description: "NIST SP 800-53 rev5 OSCAL format, on Github."
rlinks:
- rlink:
href: >-
https://github.com/usnistgov/oscal-content/tree
/master/nist.gov/SP800-53/rev4/xml/NIST_SP-800-53_rev5_catalog.xml ]]>
</tagging>
</section>

Who is the bug affecting?

Developers who implement a profile resolver.

What is affected by this bug?

Whether or not to properly resolve an internal reference to imports with base64 only elements.

When does this occur?

Consistently, if literally following the specification to make a conformant profile resolver.

How do we replicate the issue?

  1. Read the specification.
  2. Implement the profile resolver per current draft spec.
  3. Implement or not implement support to process resource with a base64 element.

Expected behavior (i.e. solution)

Unclear, depends on what we decide for the specification. 🙃

Other Comments

I reviewed the spec when developing oscal-compass/compliance-trestle#1023 for oscal-compass/compliance-trestle#1019.
@aj-stein-nist aj-stein-nist added bug Profile Resolution Issues relating to profile resolution. labels Feb 15, 2022
@wendellpiez
Copy link
Contributor

The base64 feature was envisioned to support not the dynamic information network represented by an OSCAL document (or set of documents) in a processing context, but rather appendages to that network (e.g., jpeg binaries). To use it for a catalog import or indeed a baseline import for an SSP would seem to violate the design premise of OSCAL. Such resources are typically not discoverable or checkable (or validable) until runtime, hence potentially a security issue as well (since data loss or variation is harder to detect and prevent).

As an alternative to permitting it as an option, we might consider forbidding it. It also raises a wide range of issues e.g. regarding character encodings of text-based resources (such as XML or JSON) represented in Base64.

@stephenbanghart
Copy link
Contributor

Profiles carrying entire Catalogs in Base64 to then import into itself does go against the intended usage pattern, but shouldn't be strictly prohibited IMO

Suggestion: Change the requirement to "IF an RLink is present, it MUST be used to resolve it, otherwise do what you want"

@david-waltermire david-waltermire added this to the OSCAL 1.0.2 milestone Feb 25, 2022
@david-waltermire
Copy link
Contributor

david-waltermire commented Mar 10, 2022 •
edited
Loading

@stephenbanghart The model allows both rlinks [0-∞] and base64 [0-1] to appear. There is a Metaschema constraint that requires at least one of the two appear. This means that you can have either or both in a given resource.

The Profile resolution spec should have well-defined behavior for utilizing any rlink or the base64 entry.

In the case of the rlink, an HTTP client request can be made to retrieve a byte stream to retrieve the resource. In the base64 case, the byte stream can be generated by decoding the base64 content based on the algorithm defined in RFC 4648. Decoding of a base64 resource would also follow this RFC. The decoded base64 text MUST be considered a byte stream, just like a resolved rlink. If the implementation cannot parse either resulting byte stream, it MUST produce an error.

@GaryGapinski
Copy link

Given "If the implementation cannot parse either resulting byte stream, it MUST produce an error." , I'll make a suggestion.

Both of the filename and media-type attributes of <base64> are optional in the OSCAL XML Schema. The absence of a declared media-type greatly increases the difficulty of parsing the (successfully decoded) "resulting byte stream" as considerable knowledge of byte stream signatures would be required.

The media-type attribute will likely be considered mandatory for applications which can deal with a subset of IANA media type byte streams. Such applications will likely expect that <rlink> references for which no media type can be expected upon retrieval will also require a media-type attribute.

@GaryGapinski
Copy link

Given "If the implementation cannot parse either resulting byte stream, it MUST produce an error." , I'll make a suggestion.

i think more rigorous statements are warranted.

As stipulated, there can be 0-∞ rlinks and 0-1 base64 elements subordinate to a <resource> (and the XML Schema supports that). That of course allows no <rlink> elements and no <base64> elements and thus no related parse failures.

In the absence of either, no "parse inability" can occur.

If one or more rlink elements present an href the content of each of which cannot be parsed (parsing not yet precisely defined, though the semantic import of the term is syntactic and not semantic), the either part of that statement implies inapplicability when one of <rlink> and <base64> are not present, and not when only <rlink>s are present.

When only <rlink>s are present, and one (of many) results in a parse failure, the term "either" (as opposed to "any of") fails to match the multiple cardinality of <rlink>, parse consequences thereof, and thus one is left to determine what happens when one of one or more <rlink> byte (perhaps octet is a better term) stream parse errors occur.

In the unlikely event anyone actually is bold enough to use <base64> and furthermore in concert with <rlink>, then overall parse failure consequence and error production might best be accompanied by a table showing the various outcomes of all possible combinations of "parse failures".

Since the overall paragraph mentions "retrieval" (of an <rlink> resource), the consequence of a failed retrieval is not defined. I do not think a failed retrieval is synonymous with a parse failure so the consequence of a failed retrieval should be separately defined.

@stephenbanghart stephenbanghart mentioned this issue Mar 14, 2022
Merged
@wendellpiez wendellpiez mentioned this issue Mar 14, 2022
Open
7 tasks
@david-waltermire david-waltermire linked a pull request Mar 17, 2022 that will close this issue
Profile Resolution 1.0.2 Updates #1172
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@stephenbanghart stephenbanghart

Labels
bug Profile Resolution Issues relating to profile resolution.
Projects
None yet
Milestone
OSCAL 1.0.2
Development

Successfully merging a pull request may close this issue.

Profile Resolution 1.0.2 Updates stephenbanghart/OSCAL
5 participants
@GaryGapinski @wendellpiez @david-waltermire @stephenbanghart @aj-stein-nist