Implement Support for using JSON Web Signatures for OSCAL JSON Artifacts

[david-waltermire]

User Story:

As an OSCAL JSON content creator, I need to be able to use a JSON Web Signature (JWS) (RFC7515 to provide integrity and source authentication over OSCAL artifacts I produce.

Goals:

1. Document a general approach on how JWS can be used to sign an OSCAL JSON artifact. This documentation will be in markdown and integrated into the OSCAL documentation site.
2. Identify and document as user stories any interoperability or technical issues that need to be addressed to provide a complete solution to this user story.
3. Provide examples of a signed OSCAL JSON catalog, profile, and implementation (if possible at the time this user story is addressed. If signing an implementation is not possible, document a user story to do this in the future.
4. Demonstrate signing and validating OSCAL JSON artifacts using open source tooling or create a user story for doing this.

Dependencies:

None

Acceptance Criteria

1. Use of signature algorithms must follow NIST cryptographic guidelines (e.g., FIPS 186-4, FIPS 180-4, FIPS 202).
2. Documentation on the OSCAL usage of JWS must be sufficient for interoperable implementation.
3. Examples illustrate signed OSCAL JSON artifacts that can be verified using open source tooling.

[trevor-vaughan]

@david-waltermire-nist Can there be a mapping of the tool to the associated 140-2 certification to meet the requirements in the mentioned guidelines?

[anweiss]

There should be a mention of JWE in here as well since both JWS and JWE are often used together. Also, FWIW, the JWS payload doesn't necessarily have to be JSON ... could even be XML ... CC @wendellpiez

[anweiss]

oscalkit now has preliminary support for JWS via docker-archive/oscalkit#5. It supports the following signing algorithms: RS256, RS384, RS512, PS256, PS384, PS512, HS256, HS384, HS512, ES256, ES384, ES512 and EdDSA.

[anweiss]

Also, @david-waltermire-nist are JWS and XMLDSIG our only options for signing under consideration? Given the new supply chain risk management guidelines introduced in 800-37 Rev 2., should we not also consider additional frameworks/approaches to signing? Thinking The Update Framework (TUF) or others? I foresee the process by which OSCAL "implementation" artifacts are maintained and updated as being relatively similar to the overall systems development lifecycle and software update process.

Relates to #249

[anweiss]

@david-waltermire-nist here's another interesting approach that aims to address a number of JOSE's shortcomings -> https://github.com/paragonie/paseto (https://paseto.io/). Here's the IETF I-D as well -> https://tools.ietf.org/html/draft-paragon-paseto-rfc-00

[iMichaela]

11/08/2018

@david-waltermire-nist is working on this issue.

[david-waltermire]

11/15/2018

@anweiss is working on getting feedback from team members. Will develop some examples of using JWS in the next week or so. @david-waltermire-nist suggested to also look at the JWS security considerations as input into how to restrict use of JWS for our application.

[anweiss]

FWIW, I've got JWS signing support baked into oscalkit. See https://github.com/opencontrol/oscalkit#signing-oscal-json-with-jws. It uses the go-jose library.

[anweiss]

Also FWIW, we use OpenPGP for signing CNAB bundle.json bundles. See https://github.com/deislabs/cnab-spec/blob/master/105-signing.md#signing-the-bundlejson. It's a similar use case for what we're trying to do here for signing OSCAL JSON.

[brian-ruf]

12/20/2018 PR #278 requires review.

[anweiss]

@david-waltermire-nist FWIW, CNAB is moving away from OpenPGP in favor of TUF and In-Toto for signing CNAB bundles. See cnabio/cnab-spec#82. IMO, worth taking a look at since CNAB bundles are merely JSON; very similar use case to ours.

[anweiss]

@david-waltermire-nist some additional context here re. using something like TUF. What we haven't really discussed is the notion of "storing" OSCAL artifacts, either centralized or decentralized. Something like TUF is designed around centralized storage ... aka, store and sign the artifacts in some sort of public/private repository that folks push/pull content to/from.

This then begs the question, how do we envision folks managing their OSCAL artifacts? This of course depends on the use case. Developers and more technical folks may elect to write and manage OSCAL in XML/JSON directly and manage (store and sign) these artifacts using version control. They may also have disparate OSCAL artifacts that reside anywhere. In the case where OSCAL is used via a tool that abstracts the underlying XML/JSON, then the tool/product must have a way of storing and signing the OSCAL under the hood. There's even the ambitious scenario where the products/services/systems themselves may emit and sign their own OSCAL which is embedded into the product/service/system.

So lots of different "operational" questions, for lack of a better word, that I think we may have to have guidance around in order to define a signing strategy that addresses many use cases.

[nikitawootten-nist]

Signature solutions such as XMLDSig and JWS have merit but add additional complexity and could break format conversion guarantees. The team's general guidance in the past has been to use envelope solutions (sending a signature file separately, etc) rather then relying on format-specific inline signatures.

Closing this for now.