RE: [scap-dev] Broken XML signatures in USGCB datastreams

Hi Scott,

  Thank you for your responses. If I read your responses correctly:
* canonicalization is Schema agnostic
* automatically adding any default or fixed attributes specified in Schema as part of signature validation is not consistent with [1]
* as a best practice from [2], content authors should provide any fixed and default attributes specified by Schema into their documents
* even better schema creators should not create schema which use these attribute types (which will need to be addressed as the SCAP schemas are revised)
* conversely verifiers should use a non-destructive form of schema validation prior to signature validation (according to Best Practice 25 in [2])
* both best practices should be followed in order to avoid the most common interoperability problems

I can work as best that I can to see that content produced by NIST follows Best Practice 24 to the extent possible, although I will add that applications should (perhaps must?) follow Best Practice 25.

Do you mind if I forward both of your responses to the mailing list (scap-dev@nist.gov<mailto:scap-dev@nist.gov>) from which the discussion of this issue began? You did a better job than I did countering the misconceptions surrounding signature wrapping attacks and how to avoid them and I would also like to be sure the group on that list are aware of those issues as well as both best practices.

Regards,

-Harold

[1] http://www.w3.org/TR/xml-c14n11/
[2] http://www.w3.org/TR/xmldsig-bestpractices/

From: David Solin [mailto:solin@farnamhallventures.com] On Behalf Of David Solin
Sent: Wednesday, October 22, 2014 11:55 PM
To: Cantor, Scott; Wendy Seltzer; public-xmlsec@w3.org
Cc: Booth, Harold
Subject: Re: [scap-dev] Broken XML signatures in USGCB datastreams

Hi Scott,

The Java issue does pertain to the built-in support for XMLDSIG.  Here is a reference for you:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8017171

In our case, we bundle copies of all the the schemas, and re-write the schemaLocation attribute during unmarshalling to point to our copies.  So in a very real sense, for us, schema-validation implements application-specific awareness of the ID fields during signature verification (with awareness in the data model encoded when the JAXB model classes are generated).

As for validation being indicated by c14n11, just so you know how this crazy idea popped into my head, it came from reading the bullets:

  *   Attribute values are normalized, as if by a validating processor
  *   Default attributes are added to each element
.... which are found in the definition of the term canonical form in section 1.1 of the W3C recommendation (http://www.w3.org/TR/xml-c14n11/).  I am not an attorney, but while it certainly doesn't say you have to validate... really, it certainly does appear to say you have to validate.

Anyway, you do see in the published version (http://www.w3.org/TR/xmldsig-bestpractices/) of the draft you referenced, that best practice recommendation did make it into the final:

"Best Practice 24: Signers: Do not rely on a validating processor on the consumer's end.

"Do not rely on a validating processor on the consumer's end to normalize XML documents. Instead, explicitly include default attribute values, and use normalized attributes when possible."

At least that is something!

Best regards,
--David Solin

On 10/22/2014 10:29 PM, Cantor, Scott wrote:

On 10/22/14, 11:10 PM, "David Solin" <david@joval.org><mailto:david@joval.org> wrote:



Leaving aside all other matters for now, you mentioned that validating

before canonicalizing -- and specifically adding any default and fixed

attributes -- is a necessity for interoperability.



Not validating per se (producers of documents rarely validate them), just

populating any/all attributes that need to have values, and not leaving

them implicit to recipients. If you do that, you will have interop

problems. That's just a clear lesson that's been learned over a long

period of time.



 (I agree!)  My reading of c14n 1.1 suggested this would be considered

part of canonicalization, but you seem to be saying it's not relevant?



It is not in any way part of Inclusive or Exclusive 1.x canonicalization.

They are schema-unaware algorithms, and so they cannot possibly address

adding default or fixed attributes.



 However, you also said (of adding fixed attributes before signing):

"it's a widely accepted rule".



Rule in the informal sense. Ignore it and somebody's code will probably

break.



But can you tell me, if this isn't considered part of canonicalization,

where is this rule documented?



We included it in the best practice material that wa drafted when the 1.1

specs were published (see [1] 4.2). It is not a specification rule. I

don't know that that material was ever anything but a draft, it seems to

have stalled there.



There are other considerations that come into play when validating

documents before a signature is checked, such as data type normalization.



Something in the thread mentioned Oracle making a change to Java, but I

don't know what that refers to. Validation is certainly not on by default,

it's something parsers have to be told to do. Maybe they did something in

the standardized signature APIs, none of my project's code uses those.



-- Scott



[1] http://www.w3.org/2008/xmlsec/Drafts/best-practices/Overview.html



--

jOVAL.org: SCAP Simplified.
Learn More<http://www.joval.org> | Features<http://www.joval.org/features/> | Download<http://www.joval.org/download/>