Add support for HMAC signing of OSCAL documents

[guyzyl]

User Story:

OSCAL was built and is designed to provide a code-based standardized control assessment language. One of the main ideas is to allow standardized data exchange between different systems and parties.

An issue that currently exists with this exchange is that there's no way to verify the authenticity of such produced documents. This is the same as HTTP vs HTTPS, with utilizes digitally signed certificates to allow verifying the authenticity of the domains of the websites you use.

I suggest adding support for signing OSCAL documents, with HMAC being the initial use-case. By utilizing HMAC signatures, a document receiver would be able to:

• Verify the authenticity of the author
• Verify the authenticity of the content

Adding such feature would be a major stepping stone in enabling OSCAL based document exchange, and will allow doing so in the safe and secure manner that is required from security systems and parties.

Goals:

Add a way to verify the authenticity of OSCAL documents content and their author.

Example:

Just as an illustration, one possible "implementation" for this features is:

{
    "profile":{
        ...
    },
    "signature": {
        "type": "hmac",
        "key": "eda0faef842edcc9cca40524de8a6bdf890a1f37b663d0b982b57ec5772c88bfa27ed5034dd144a6f7b5139ec7e607d922bf2141768cb58e2e70e88fbc53c10c428d357b4f256534a776e1953d06a223c10abdf7515c167dcc4638919125d73067ecfeddd0dba1713f65a8bcf8a70d201e23c2c9e58ce4aa7dc97e2bd066e083510bce83e8bf46d317e55e1042b19cbab2a2a2f124946597a37ea729adcc34e892fc79d574eb663f3a5f7751f91cd8f17be03e9b8b4ec9df4ed45f2e3c45cb361831b05efbca3893a81c21fdb6fc0a3cd9c777a0a23c8d42684aef04ccfb433203e6c676e9ecf3a3f20d48325dd2c32f4fdec040d974346e6cac0b325afc0140",
        "algorithm": "SHA256",
        "digest": "f6e18e9fff7973c5d97bc4a308b1aa036147702ae4ba757365bdc31e1256069e"
    }
}

Acceptance Criteria

• [ ] All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• [ ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• [ ] The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

[bradh]

If you have the key, what stops you modifying the digest value? If you trust the file, what stops someone else putting a different key value in?

Also, for things that have alternative representation, you could well get different results for the same OSCAL model depending on how its serialised out.

Maybe it would be useful to go back a stage, and say what threats you are trying to mitigate? Modelling those threats might help to identify different approaches (but not XML Signature).

[david-waltermire]

This relates to #245.

Enveloped signatures such as what you are suggesting above are problematic, since the signing approach needs to determine what is signed minus the signature. There are also canonicalization issues to worry about to come up with a deterministic way of computing the hash.

JSON Web Web Signatures avoid both of these issues by using an enveloping signature that contains the signed data. It treats the signed data as a series of bytes avoiding the canonicalization issues. #245 discussed some of this. JSON Web Web Signatures can be used now without any specific OSCAL support.

[bradh]

I guess it depends on what we're trying to achieve. If a tool reads in a catalog in JSON format and outputs equivalent (but not byte identical) JSON, then canonicalization might be really important if you are saying that the output is still what was originally approved.

Of course, it won't help if I output the catalog in XML or YAML.

Not sure what (if any) of that would be important or not, hence the importance of identifying the specific threats this is meant to mitigate.

[guyzyl]

@david-waltermire-nist this is defiantly related to #245. Closing this one in favor of continuing the discussion in a unified ticket.