Design Support for Using XML Digital Signatures for OSCAL XML Artifacts

[david-waltermire]

User Story:

As an OSCAL XML content creator, I need to be able to use XML Digital Signatures (XMLDSig) to provide integrity and source authentication over OSCAL XML artifacts I produce.

Goals:

1. Document a general approach on how XMLDSig can be used to sign an OSCAL XML 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. Document a user story to provide examples of a signed OSCAL XML catalog, profile, and implementation.
4. Document a user story to demonstrate signing and validating OSCAL XML 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. Additional user stories are documented.

[david-waltermire]

Source: http://jvnrss.ise.chuo-u.ac.jp/jtg/xsig/en/index.02.html

As illustrated above there are 3 forms of signatures supported by XMLDSig:

1. Detached - The signature is a separate XML resource that points to the content being signed.
   Pros:
   • Simple signing process.
   • Multiple signatures can be made over the same content.
   • The original content is not modified in any way by the signature.
     Cons:
   • Since the two are decoupled, the content and signature are separate and need to be managed as a group. If content is retrieved/copied, the two may become separated. This is a big negative of this approach.
2. Enveloping - The content is embedded within the signed portion of the signature.
   Pros:
   • Simple signing process.
   • The signature and content are coupled.
   • The original content is not modified in any way by the signature.
     Cons:
   • The signature must first be parsed, before the content can be parsed
   • Multiple signatures require enveloping an existing signature; which complicates signature validation.
3. Enveloped - The signature is embedded within the content.
   Pros:
   • The signature and content are coupled.
   • The content can be parsed, without the need for the parser to be "signature aware".
   • Multiple signatures can be included in the same content, at the cost of more complicated signature validation.
     Cons:
   • More complex signing process.
   • The original content is modified to insert the signature; a transform is used to identify the signed portion of the content.

I have used all 3 methods of XML signing in the past.

• Detached is not a great solution, since the signature and content are decoupled. As content is passed around, it is easy for the signature to be lost. This makes this solution difficult to manage and use to provide document integrity.
• Enveloping is ok, but it requires all parsers to be aware of the signature. This is not a huge deal breaker, but it does complicate development of tools that do not need to use the signature.
• Enveloped is the best solution IMHO, and has worked well in many efforts I have been involved in. The positive/negative tradeoffs provide a good balance. This approach requires more specification/restriction around how to do the signature, but this added complexity only needs to be addressed by tools creating and validating signatures.

Looking for other opinions on which approach to use. Thoughts?

[david-waltermire]

There are a number of XMLDSig best practices to also consider:

• Best Practice 1: Implementers: Mitigate denial of service attacks by executing potentially dangerous operations only after successfully authenticating the signature.
• Best Practice 2: Implementers: Establish trust in the verification/validation key.
  • Note: this often involves validating the certificate chain of the certificate.
• Best Practice 3: Implementers: Consider avoiding XSLT Transforms.
  • Note: We will want to disallow arbitrary XSLT Transforms.
• Best Practice 4: Implementers: When XSLT is required disallow the use of user-defined extensions.
  • Note: See 3 above.
• Best Practice 5: Implementers: Try to avoid or limit XPath transforms.
  • Note: We will want to disallow XPath Filter Transforms.
• Best Practice 6: Implementers: Avoid using the "descendant", "descendant-or-self", "following-sibling", and "following" axes when using streaming XPaths.
  • See 5 above.
• Best Practice 7: Implementers: Try to avoid or limit ds:RetrievalMethod support with ds:KeyInfo.
  • We will want to disallow use of this.
• Best Practice 8: Implementers: Control external references.
  • Note: We will want to disallow use of external references, unless we support detached signatures.
• Best Practice 9: Implementers: Limit number of ds:Reference transforms allowed.
  • Note: We will want to limit transforms to document "identify" transforms and signature transforms that are used to ignore embedded signature(s).
• Best Practice 10: Implementers: Offer interfaces for application to learn what was signed.
• Best Practice 11: Implementers: Do not re-encode certificates, use DER when possible with the X509Certificate element.
• Best Practice 12: Applications: Enable verifier to automate "see what is signed" functionality.
• Best Practice 13: Applications: When applying XML Signatures using XPath it is recommended to always actively verify that the signature protects the intended elements and not more or less.
  • Note: See 5 above.
• Best Practice 14: Applications: When checking a reference URI, don't just check the name of the element.
  • Note: See 8 above.
• Best Practice 15: Applications: Unless impractical, sign all parts of the document.
  • Note: This is a good practice.
• Best Practice 16: Applications: Use a nonce in combination with signing time.
• Best Practice 17: Applications: Do not rely on application logic to prevent replay attacks since applications may change.
• Best Practice 18: Applications: Nonce and signing time must be signature protected.
• Best Practice 19: Applications: Use Timestamp tokens issued by Timestamp authorities for long lived signatures.
• Best Practice 20: Applications: Long lived signatures should include a xsd:dateTime field to indicate the time of signing just as a handwritten signature does.
• Best Practice 21: Applications: When creating an enveloping signature over XML without namespace information, take steps to avoid having that content inherit the XML Signature namespace.
• Best Practice 22: Applications: Prefer the XPath Filter 2 Transform to the XPath Filter Transform if possible.
• Best Practice 23: Signers: Do not transmit unparsed external entity references.
• Best Practice 24: Signers: Do not rely on a validating processor on the consumer's end.
• Best Practice 25: Verifiers: Avoid destructive validation before signature validation.
• Best Practice 26: Signers: When using an HMAC, set the HMAC Output Length to one half the number of bits in the hash size.
• Best Practice 27: Signers: When encrypting and signing use distinct keys

IMHO, we should follow the best practices for Implementers, and provide strong recommendations in the form of guidance for Applications, Signers, and Verifiers. Thoughts?

[iMichaela]

11/08/2018

@david-waltermire-nist would like feedback from @anweiss, @brianrufgsa, and @redhatrises on the comments left above

[david-waltermire]

11/15/2018

Mark this as completed.

@david-waltermire-nist will create issues around 1) documenting the XMLDSig approach and 2) developing a signing/validating implementation for testing of the approach.

Note: signature creation and validation need to be optional activities in OSCAL.

[david-waltermire]

User story #345 has been created to address the development work for this.