What are the semantics of multiple rlink / base64 elements within a resource?

[bradh]

A profile can import a file either directly, or indirectly via a resource. Within resource, rlink can appear multiple times. base64 can also appear.

If it does, what are the semantics? Are these considered interchangeable (i.e. any one will do), or do they comprise a composite that make up the resource? In particular, what does it mean for profile resolution to import a catalog as a resource that has more than one rlink associated?

[brian-ruf]

@bradh, NIST intended tool developers to make their own decisions about how a tool should respond when a resource contains both an rlink and base64. A tool could always give preference to one, or it could compare them and alert the user if a difference is detected.

While some files in resource won’t be OSAL files, in the case of profile resolution, a tool could look at the last-modified date of both OSCAL files and select the newer of the two, or alert the user of both dates and ask which to use.

These are just scenarios/examples we considered. It is entirely up to the developer how to handle a resource with both an rlink and base64.

[bradh]

I am sympathetic to the need for flexibility, but this looks like an interoperability / consistency problem. I want resolution of profile A to consistently result in catalog B. That doesn't look possible given the flexibility identified above.

For the base64 case, there is no timestamp. So you need to go back to a comparison, and its quite possible that the files can be semantically equivalent but binary different. That puts a lot of onus on users to work out the XML or JSON differences.

I'd like something better defined, at least for the profile resolution case. An easy option would be that if you are using a reference, its always to a base64 resource (i.e. not an rlink). If you want to do an external file, that goes in the import statement as a direct link. I would also be happy with that case being restricted to a single base64 or a single rlink (based on the media-type which would have to be required for a profile resolution target).

Even an explicit statement that its user defined and noting the issues would be better than nothing.

[brian-ruf]

@bradh, I think you are raising a good point that if we are to allow both rlink and base64 in a single resource, it may not be enough just to compare the content of the two for differences. Would it be helpful to include some additional information about base64-embedded content, where practical?

In the "Guide to OSCAL-based FedRAMP SSPs", I declared a preference for embedded (base64) attachments over rlink, because the SSP (OSCAL) files are currently passed around for review and adjudication in different intranets, where the links are likely to be unreachable.

Other OSCAL user communities may not have this concern, and may prefer rlink, especially if the linked files change more frequently.

NIST didn't want to force one or the other, and while I was also leary of that much flexibility, I have come to appreciate the wisdom in it. Still, I needed to declare a preference for FedRAMP's processing of these files and selected the best one for our circumstances.

[bradh]

Possibly the answer depends on whether we think an OSCAL SSP is human readable.

If the normal case is that it'll be viewed in a tool or a post-processed form (markdown, PDF, etc), then maybe we would be better off removing the base64 part (which obviously won't be readable anyway), and working out some kind of packaging approach, like a zip file. The rlink would then point to a "local" file.

If we want to borrow semantics and support, Open Packaging Conventions could be a possibility.

That isn't to say OSCAL files should always be zipped, just trying for something that could be a worthwhile extension / profile.

[david-waltermire]

The initial intent was that rlink items and base64 would be alternatives for content acquisition. The base64 would be embedded and most trusted. The rlinks would point to mirrors of the same remote resource.

[brian-ruf]

30-Jan-2020 Status

@david-waltermire-nist added content to the documentation portion of the metaschema to clarify intentions and handling of this as part PR #553.

[david-waltermire]

This is addressed by PR #619.